CICA 1993 August

home *** CD-ROM | disk | FTP | other *** search

/ CICA 1993 August / CICA.cdr / unzipped / programr / wpjv1n1 / wpjv1n1.txt < prev

Wrap

Text File | 1993-01-02 | 70.9 KB | 1,916 lines

WW WW WW PPPPPPPP JJ WW WW WW PP PP JJ WW WWWW WW PP PP JJ WW WW WW WW PPPPPPPP JJ WW WW WW WW PP JJ JJ WWWW WWWW PP JJ JJ WW WW PP JJJJJ ---------------------------------------------------------------- The Windows Programmer's Journal Volume 01 Copyright 1992 by Peter J. Davis Number 01 and Mike Wallace Jan 93 ---------------------------------------------------------------- A monthly forum for novice-advanced programmers to share ideas and concepts about programming in the Windows (tm) environment. You can get in touch with the editor via Internet or Bitnet at: HJ647C at GWUVM.BITNET or HJ647C at GWUVM.GWU.EDU CompuServe: 71141,2071 or you can send paper mail to: Windows Programmer's Journal 9436 Mirror Pond Dr. Fairfax, Va. 22032 The two GWUVM IDs are Pete's and CompuServe is Mike's. We can also be reached by phone at: (703) 503-3165. Microsoft, MS-DOS, Microsoft Windows, Windows NT, Windows for Workgroups, Windows for Pen Computing, Win32, and Win32S are registered trademarks of Microsoft Corporation. Turbo Pascal for Windows, Turbo C++ for Windows, and Borland C++ for Windows are registered trademarks of Borland International. WordPerfect is a registered trademark of WordPerfect Corporation. The Windows Programmer's Journal takes no responsibility for the content of the text within this document. All text is the property and responsibility of the individual authors. The Windows Programmer's Journal is solely a vehicle for allowing articles to be collected and distributed in a common and easy to share form. No part of the Windows Programmer's Journal may be re-published or duplicated in part or whole, except in the complete and unmodified form of the Windows Programmer's Journal, without the express written permission of each individual author. The Windows Programmer's Journal may not be sold for profit without the express written permission of the Editor, Peter J. Davis, and only then after he has obtained permission from the individual authors. Table of Contents Subject Page Author(s) ----------------------------------------------------------------- WPJ.INI ...................................... 3 Pete Davis Off Topic .................................... 6 Pete & Mike Beginner's Corner (C) ........................ 8 Pete Davis & Mike Wallace A Drag and Drop Trashcan (TPW) ............... 16 Andreas Furrer Using DDE to Communicate With Program Manager. 18 Pete Davis Implementing a Linked List in the Global Heap. 22 Mike Wallace Book Review .................................. 26 Pete Davis Last Page .................................... 28 Mike Wallace Getting in Touch with Us ..................... 29 Pete & Mike Windows Programmer's Journal Staff: Publishers ......................... Pete Davis and Mike Wallace Editor-in-Chief .................... Pete Davis Managing Editor .................... Mike Wallace Contributing Writer ................ Andreas Furrer WPJ.INI First of all, I'd like to introduce myself. My name is Pete Davis and I was the editor of the Pascal NewsLetter, a journal similar to this one which lasted 1 year for 6 issues. I unfortunately had an accident which left me unable to continue the newsletter for some time. By the time I was back in shape and ready to go, someone had picked up the newsletter and re-started it. It was nice to see that there was enough interest that it could continue without me. In the past year I have developed an interest in Windows programming using C, so I guess at this point, I'm more suited to Windows programming anyway. Well, it sure is nice to have a "magazine" again. I guess I have the same problem now that I had with the Pascal NewsLetter: What is it? A magazine? A Journal? A NewsLetter? Well, I never quite got it figured out. The Pascal NewsLetter was originally intended to be just that, a newsletter, but in its prime it was over 30 pages single-spaced, so it wasn't exactly a newsletter. What, you may ask, is the purpose of this thing anyway? Well, I love to program. I know a lot of other people out there, techno-geeks like myself, love it also. As with Pascal, I'm finding there aren't a whole lot of magazines which cover Windows programming. That's fine, it just leaves more readers for us, I suppose. Not to mention, this is free. There aren't any free ones for Windows programming (or if there are, I haven't heard of them). I like to teach people how to program and I can't think of an easier way to get such a large audience and have it all be free. In this magazine, you won't just be hearing Mike and I ramble on, but you'll be hearing from a lot of people. Not professors, not industry experts, but people like you and me, regular programmers who like what they do and want to share their ideas and experiences with us. No one gets paid and no one has to pay. That's the idea. If the initial response we got, when we first started asking people about doing this, is any indication, there are going to be a LOT of readers. That means we should also have a lot of writers. You'll find a file in this .ZIP file with the name SUBMIT.TXT. It is simple instructions on how to submit an article. There aren't any solid rules and it's easier than you'd probably expect, so please consider sending in an article. Right now, things are real open to regular columnists. I had several with the Pascal NewsLetter and their columns were very well received. Since we don't have a regular columnist for a beginners column yet, Mike and I are going to start it up ourselves, but I hope someone will try to pitch in and give us a hand with it. When I did the Pascal NewsLetter, I had a regular writer for a beginners column and it was the most popular column in the magazine. There's a reason for that. There are a lot of people trying to get started and just can't seem to get the hang of the basics. Programming Windows is a lot different than programming in DOS and it's not as easy to pick up, but with a little persistence, anyone can do it. Other columns that we'd like to see are ones that address things like C++ for Windows and Turbo Pascal for Windows. We'd like to hear from you if you want to tackle any of these. It's not a lot of work and only requires a few hours each month. Most of us can make at least that much time. The Pascal NewsLetter came out irregularly, but we'd really like to do this on a monthly basis if possible. If we don't get enough submissions, we might have to make it every two months. We should be able to let you know by the second or third issue. As far as things we'd like to see in the newsletter: * Software and book reviews, maybe even reviews of Windows related hardware. I'd like to see reviews every month. * As I mentioned before, I want a beginners column for plain C for Windows as well as one for Turbo Pascal for Windows and C++ for Windows. * As far as one-time articles, perhaps one on programming DLLs and special considerations that need to be made for writing them. * Articles on DDE and OLE programming. * Articles on network programming in Windows for Workgroups and Windows NT. * Printing text and graphics in Windows * Memory management * Using different memory models and how to handle multiple code or data segments. * Programming TCP/IP and Sockets under Windows NT * Maybe reviews of Windows NT while it's still in the pre-release stage to let people who don't have it know what it's like and how Microsoft is progressing with it. That should be enough to start with. Please take the time and try to contribute. You don't have to be an expert. In the Pascal NewsLetter, the beginner's column was written by a guy who was just learning Pascal. He did a fantastic job, and as I said earlier, it was the most popular column. I had an article submitted to me by someone who didn't speak English very well, so he wrote it in his native tongue, German, and I had it translated. I had a 16 year-old high school student who submitted a terrific article, so anyone can do it. You just need to take the time. The writing in this magazine is pretty informal. People seemed to like that about the Pascal NewsLetter. They said it was easier to relate to than regular magazines, so I'm going to stick with that format. As for the format, I'm going to try to keep it like I did with the Pascal NewsLetter, in that it's just a plain text file with Form Feed characters at page breaks. If there's a big push to go with something like the Windows Write format, that can be done too. Personally, I prefer using WordPerfect (just what I'm used to) and it makes it pretty easy for handling formatting and getting articles from different people in different formats. In fact, as far as anything about the magazine, if you have suggestions, we'd love to hear them. If you think we should change the way we're doing something, then you might not be the only one. If we get enough suggestions for things, or if it's just something we should obviously be doing then we'll make the change. Well, that's enough of my rambling on for now. Hope you guys (and gals) like the magazine. I'm open to suggestions and I love to get feedback, good and bad, about the magazine, so feel free to get in touch with me or Mike at the address on the cover page. Off Topic By Pete and Mike This is exactly what the title says, off topic. Mike and I have two computers that we want to sell, so we figured we may as well throw those in here. Both machines are identical. They are: IBM PS/2 Model 70-486 (8570-B61) Both machines have 2MB RAM and 60 MB hard drives. They come with 8512 Color VGA monitors and the IBM Enhanced Keyboards. The machines are less than 4 months old and barely used. The cost is $1,500.00 and includes shipping anywhere in the continental United States. Shipping outside of the United States is covered by the buyer. These machines are really in excellent condition. We've checked them out thoroughly and there aren't any problems with them. We'll throw in a guarantee that if there are problems with them sometime within the first month, you can return the computer for a full refund. Of course this doesn't include any damage applied after the purchase. Well, that's our little pitch for our computers. We don't normally sell computers, so hopefully this will be the only ad we throw in here for computers. Our next off-topic thing is something Mike and I discussed and both of us agreed that it wasn't something we wanted to do but felt that for the magazine's best interest, we would. We are asking for donations. Neither of us is looking to make a fortune in contributions (And I'd be willing to put money down that we don't). The idea behind it is this. We want to be able to support Windows programming with different compilers, Windows NT, Windows for Workgroups, etc. The donations would be used specifically to get the software so we could either work with these environments for our own articles or use them to test programs and articles sent in by others. Our address is at the end of the article. Send in what you believe this magazine is worth. We want to put together the best Windows magazine out there, but we're not rich, so we'll do what we can with what we have. If you do want to send a donation, see the last page for our address. Make the check payable to Pete Davis. Beginner's Corner By Pete Davis and Mike Wallace Well, since this is the first issue and we don't have a writer for the beginner's column yet, Mike and I are going to split it between the two of us. I'm a strong believer in the beginner's column because once you make the first few steps, you get hooked. Unfortunately, few books really address the beginner so someone has to help them get started. We must assume that the reader is familiar with the C language. Covering both a beginners column for C and for Windows would be far too great a task. There are several good books out for C programming and there's also the C News, which, like this magazine is a file which is available on many BBSes and the Internet. It's a great place to start learning C and I highly recommend it. Also, although formally, all C routines are called functions, we use the words procedure, function, and routine fairly interchangeably. A function tends to imply that some result is returned to the calling routine so I tend to use it in that manner. In almost every beginners book on programming, the first program written is the infamous "HELLO WORLD" program. We're going to do that here, but in a sort of round-about way. We're not just going to show you the one simple program, but we're going to go to great lengths in explaining the different parts of a Windows program first. For example, I'm going to specifically cover how Windows works and then the .DEF file which is used to tell the compiler how your code and data is supposed to be configured when it's linked. Then Mike and I are going to go in-depth into the .RC or Resource source file. The .RC file has the definitions of all the resources of your program. It has your dialog boxes, menus, icons, bitmaps, etc. We won't actually get to the "HELLO WORLD" program itself until the second issue. To a beginner, it may seem a bit overwhelming that we're going to have to cover so much just to do a "HELLO WORLD" program, but the truth is, we don't HAVE to cover all of it. When you actually see the program, you'll see how simple it really is. We'd just like to give you an overview of the parts of a Windows program first and then show you a specific example. We'd also like this article to be a sort of reference on how to create more than just the simple resources and definitions (.RC and .DEF files) for a "HELLO WORLD" program. How Windows Works Too some of you who are beyond the very basics, some of this you may already know, but it may be a good idea to read anyway. Some of this is a simplified explanation, but the point is to get the concept easy to understand. Later we can be a little more specific. Windows is what is called a non-preemptive multi-tasking environment. A preemptive multi-tasking environment is one where the operating system allocates a certain amount of time to each task. It then runs one task until it has used its share of time and then runs another task until its time has run out and so on until it gets back to the first task. Windows, on the other hand, will run a procedure from your program until the procedure is completed and then it will run a procedure from another program until it is completed. What this means is that a Windows program can take over the CPU entirely, if it wants, but that defeats the purpose of programming for a multi-tasking environment. (There is one exception, and that is DOS sessions running under Windows, which are handled in a preemptive manner, but this is not our topic and won't be discussed in this column.) In a Windows program, the initialization of the program first 'registers' itself with Windows. It does this by telling Windows a few parameters that it needs to know about the program and to set-up the main message-loop, then telling Windows where the main window procedure is. A message-loop procedure is one that accepts messages from Windows that are sent to your program. Messages in Windows are a way of telling your program what the user is doing, or a way for your program to tell Windows or some other program what to do. Windows messages usually come in the form of WM_something, where the WM_ stands for Windows Message. For example, when you first create your Main Window, one of the first messages passed to your procedure is WM_CREATE. When you receive the WM_CREATE message, you know Windows is about to create your window and if you want to initialize certain variables to be handled by that procedure, you want to do it now. Or, if you receive the WM_CLOSE message, you know that Windows is about to close your window and end your program. You may want to, at this point, ask the user if he wants to save his files or ask if he really wants to quit. Messages are the heart of the Windows multi-tasking environment and when we create our "HELLO WORLD" program, you'll see a little more clearly how this works. In your programs, you will create windows and dialog boxes. When you do that, you need to tell Windows the name and location of a procedure which is going to handle the messages used by the window or dialog box. The procedure then gets all messages pertaining to that specific window or dialog box. Each of these procedures is a lot like the main window procedure to Windows. This is unlike a regular DOS C program in which the program always controls which procedure is called next and is responsible for making its own calls. In a Windows program, you tell Windows where your procedures are and it will run them in response to certain commands and user actions. This may seem a little unclear, but all I can say is stick around until the end of the second part of the article and it may make more sense in terms of a real program. This is, essentially, how Windows works. If you have questions, please feel free to contact us in one of the ways mentioned on the first page and we will try to be more clear in the areas readers seem confused about in the second part of this article. The .DEF File (Also known as the Module Definition File) The .DEF file is what the compiler uses to find out how to handle your program as a whole and how to handle individual routines in your program. We're going to go fairly in-depth into the different things you can do in a .DEF file, but in the second part of the article, you'll see a very simple application .DEF file and see exactly what parts are basic. I will try to distinguish between the things that you always must have and then parts that are optional or rarely used. I will show each parameter, a summary of its purpose and options, followed by how it would appear in the .DEF file. The .DEF file is simply an ASCII text file that you type in with your program editor. The first parameter is the NAME. In general, this should be the same as the name of the executable. Also, in the cases of Dynamic Link Libraries (DLLs), this is replaced by the LIBRARY parameter. NAME myprog (for a regular Windows program) or LIBRARY mydll (for a DLL) The next parameter is the DESCRIPTION. This is inserted into the header of your executable, but serves no real purpose other than perhaps allowing you to keep track of version and/or copyright information. DESCRIPTION 'My first Windows Program' The EXETYPE parameter tells the compiler which environment the program will be run under. For Windows, it is simply: EXETYPE WINDOWS The next parameter is the WINSTUB program. The WINSTUB is simply the name of a program that is run in the event that someone tried to execute a Windows program under DOS. This may be familiar to you. The most common WINSTUB is the one that says, 'This program requires Microsoft Windows.' In theory this program can be almost anything you want. A programmer could, for example, have both a DOS and Windows version of his/her program with the DOS version simply being a WINSTUB in the Windows version. In a later article, I'll provide source code for a WINSTUB that will allow a user to run your Window program from DOS. This is done by running Windows with the name of the program as the parameter (i.e., the user types 'TESTPROG' and the stub from TESTPROG executes the command: 'WIN TESTPROG'). The possibilities are enormous and it would be nice at some point to see some more creative uses of the WINSTUB besides 'This program requires Microsoft Windows.' Anyway, the standard WINSTUB is a program called WINSTUB.EXE which comes with most Windows compilers. The syntax is as follows: WINSTUB 'WINSTUB.EXE' The next section covers the code and data segments. Windows has the Small, Medium, Compact and Large memory models. The memory model determines whether or not there are multiple code and/or data segments. See the following table: Model # Data Segments # Code Segments ---------------------------------------------------------- Small Single Single Compact Multiple Single Medium Single Multiple Large Multiple Multiple For now, we'll stick mostly with Small or Medium models, as they're the easiest to use. We will go into the different models in later articles to discuss the advantages and disadvantages of each and how to program for them. Each code and data segment can have different options telling Windows how to handle them. Most segments, you want to give the option MOVEABLE which means that the Windows memory manager can move the segment around in memory to make room for other things if needed. There may be occasions when you would want a segment set to FIXED. For example, if you were writing a program that was working with DOS on a fairly low level, it is useful to have things set for FIXED so DOS will always know where they are. This is, however, in the advanced arena, so we'll be avoiding it. The PRELOAD option tells Windows to automatically load the segment into memory before the program is actually executed. The LOADONCALL option tells Windows only to load the segment when it is needed. This helps keep memory available for other processes. In general, you want your main CODE and DATA segments set for PRELOAD. The DISCARDABLE option tells the Windows memory manager that it can remove that segment from memory all together when it needs more memory. The memory manager will then re-load the segment the next time it is needed. This is fine for most CODE segments where the contents of the code does not change. In DATA segments, the contents of the data will change as the program is run and because of this, you do not want it to be discardable. The discardable segments are not saved before they are discarded, so any changes made to them are lost. Making a DATA segment discardable would give unknown results. The SINGLE option tells windows tells Windows that although there may be multiple copies of the program running at once, that this segment may be shared. This is useful for a CODE segment where several copies of the same program can use the same copy of the code, thus saving memory. The DATA segment, however, would be different from one running program to the next, so the SINGLE option wouldn't really be appropriate. (Because of the way Windows handles DLLs, they data segments MUST be SINGLE. This requires special handling on the part of the programmer to handle multiple programs using the same DLL. We'll discuss this another day.) The MULTIPLE option tells Windows to create a separate copy of the segment for each copy (instance) of the program that is being executed. This is useful for DATA segments. If your CODE segment is single and your DATA segment is multiple, you can share the CODE segment and save memory, but each copy (instance) of the program will have its own data. The following is an example for a Small model program. It has one code segment and one data segment. CODE PRELOAD MOVEABLE DATA PRELOAD MOVEABLE MULTIPLE The next parameters are Heapsize and Stacksize. Heapsize refers to how much space is available for local dynamic memory allocation. If you are familiar with dynamic memory allocation in regular C programming, then this is nothing really new to you. The only real difference is in Windows you have Global and Local heaps. For now, let's just keep the Heapsize at about 4096. This is a nice safe size for the types of programs we're going to be doing for a while. The stacksize tells Windows how much space to make available for the stack. The stack is where Windows keeps a lot of it's variable declarations. It also keeps information when you call procedures and functions here. As with Heapsize, 4096 should do fine for the time being. The syntax is as follows: HEAPSIZE 4096 STACKSIZE 4096 The next section is the EXPORTS and IMPORTS sections. The exports are procedures that will be called by something other than your own program. For example, your main window procedure that receives all the messages regarding your main window is an exported procedure. Any procedure that accepts messages, for that matter, are Exported. These procedures receive their messages from Windows and are called by Windows. Each procedure exported should be followed by an @n where n is an integer number. The number is an unique index number that Windows uses to help it keep your program organized. It's not required, but it does help speed things up for Windows and I suggest you use it all the time. Imports are functions that you want to use from external sources, like a DLL, or some other source. To use those, you simply need to list them. If they come from a DLL, you need to do the name in the form of: DLLNAME.FUNCTIONNAME. EXPORTS MainWndProc @1 ADlgProc @2 IMPORTS SHELL.DRAGQUERYFILE Well, that about covers the .DEF file. As we start to use it more regularly, you'll see how the different sections affect the program. So, we'll end this section with a sample .DEF file. NAME MYPROG DESCRIPTION "My first Windows program" EXETYPE WINDOWS STUB 'WINSTUB.EXE' CODE PRELOAD MOVEABLE DATA PRELOAD MOVEABLE MULTIPLE HEAPSIZE 4096 STACKSIZE 4096 EXPORTS MainWndProc @1 The .RC File The .RC file is used to define the resources for a Windows application. Resources include icons, cursors, menus, dialog boxes, bitmaps, fonts, string tables, accelerators, custom resources and version information; in other words, the gist of a Windows program. The .RC file can contain either definitions for one or more of each of these resource types or tell Windows where to find the definition(s). I'll start with the dialog box format this issue. A dialog box is a type of window allowing the user to, for example, select an item from a list box, pick a printer, select a drive for a file directory, etc. In other words, whenever you want to display information to the user or get input, use a dialog box. The "About" box is a dialog box. The difference between a dialog box and a window is that a window is normally used for drawing graphics and a dialog box displays text ("dialog"). You define a dialog box with the DIALOG statement, which has the following format: name DIALOG [load option] [memory option] col, row, width, height [option statements] BEGIN [dialog box items] END Description of parameters: name - unique (to your program) name for the dialog box load option - determines when the dialog box is loaded into memory; if specified, must be either PRELOAD or LOADONCALL. PRELOAD tells Windows to load the dialog box when the application starts. This makes the box appear quicker, but takes up memory since it must stay in memory throughout execution of your program, even if your program never loads it (based on user input, for example). The default, LOADONCALL, tells Windows to load it when necessary. memory option - combination of FIXED, MOVEABLE and DISCARDABLE. This should normally be "MOVEABLE DISCARDABLE" (notice there's no comma). See the article "Implementing a Linked List in the Global Heap" elsewhere in this issue for a discussion of these attributes. row,col,width,height - position and size of the dialog box; col (column) and row specify the location of the upper left corner of the dialog box relative to the upper left corner of the window which called it. All dimensions are in dialog base units. option stmts - describe the dialog box; can include the STYLE, CAPTION, MENU, CLASS and FONT. These are described below. STYLE - Format "STYLE style". Valid values for style are a subset of the styles for windows. Any window style starting with WS_ or DS_ can be used (except for WS_MINIMIZEBOX and WS_MAXIMIZEBOX), and combined with "|". These are listed below: DS_LOCALEDIT - Forces memory used by dialog boxes into the application's data segment. DS_MODALFRAME - Creates a dialog box with a modal frame. DS_NOIDLEMSG - No WM_ENTERIDLE messages are sent from the dialog box if created with this style. WM_ENTERIDLE messages are normally used to alert the application that the dialog box is displayed but no user activity has happened yet. DS_SYSMODAL - System modal dialog box. This means no other window can gain the input focus until this dialog box is closed. WS_BORDER - Border on the dialog box. WS_CAPTION - Caption on the dialog box; can't be used with WS_DLGFRAME WS_CHILD - Create a child dialog box; can't be used with WS_POPUP. WS_CHILDWINDOW - Same as WS_CHILD. WS_CLIPCHILDREN - When creating a parent dialog box, specifies that child dialog boxes will be clipped at the boundary of the parent. WS_CLIPSIBLINGS - Used with WS_CHILD; keeps "sibling" dialog boxes from overlapping. WS_DISABLED - the dialog box is initially disabled (cannot receive the input focus). WS_DLGFRAME - Double border. WS_GROUP - The control can be reached via the direction keys (arrows). WS_HSCROLL - Horizontal scroll bar. WS_ICONIC - Initially iconic; used with WS_OVERLAPPED. WS_MAXIMIZE - Initially maximized. WS_MAXIMIZEBOX - Maximize box in the upper right corner. WS_MINIMIZE - same as WS_ICONIC. WS_MINIMIZEBOX - Minimize box in the upper right corner. WS_OVERLAPPED - Caption and border. WS_OVERLAPPEDWINDOW - Combination of WS_OVERLAPPED, WS_CAPTION, WS_SYSMENU and WS_THICKFRAME (standard parent window style). WS_POPUP - Popup dialog box (can't be used with WS_CHILD). WS_POPUPWINDOW - Combination of WS_POPUP, WS_BORDER and WS_SYSMENU (standard popup window style) WS_SYSMENU - System menu. WS_TABSTOP - Specifies at which control the tab key stops. WS_THICKFRAME - Thick frame (used to size the dialog box). WS_VISIBLE - Initially visible. WS_VSCROLL - Vertical scroll bar. Example : STYLE DLGFRAME | WS_VISIBLE CAPTION - Format "CAPTION text". Gives a caption of "text" to dialog boxes defined with the WS_CAPTION style. MENU - Format "MENU menuname". Assigns menu "menuname" to the dialog box. The menu is normally defined in the .RC file. CLASS - Format "CLASS classname". Causes a class other than the class of the parent window to be used for the dialog box. FONT - Format "FONT pointsize, typeface". Determines the font size used for the dialog box, which in turn determines the sizing of every control and the dialog box itself. Example : FONT 10, "Helv" Defining Dialog Box Items: Defining the objects in a dialog box (e.g., a check box) occurs between the "BEGIN" and "END" statements. A lot of these control statements have as part of their parameter list "col, row, width, height". These give the size and location of the object, and must be integers. Some objects have a "text" field, which can be any string enclosed in quotes (e.g., "Cancel"). Most of the time, the optional "style" parameter can be either WS_TABSTOP or WS_GROUP or the two combined using "|". The "id" parameter is a unique identifier assigned by the programmer, with the exception of static text controls, which are usually given an ID value of - 1 since they are never selected. The control statements are described below: CHECKBOX - Format "CHECKBOX text, id, col, row, width, height [, style]". Defines a check box control. COMBOBOX - Format "COMBOBOX id, col, row, width, height [,style]". Defines a combo box control. This is a combination of an edit control and a drop- down list box. The optional style parameter can include any combination of WS_TABSTOP, WS_GROUP, WS_DISABLED and WS_VSCROLL. CONTROL - Format "CONTROL text, id, class, style, col, row, width, height". Specifies all forms of child window controls within a dialog box. The "class" parameter can be either "button", "combobox", "edit", "listbox", "scrollbar" or "static". The "style" parameter can be any of the allowed values for CreateWindow(). CTEXT - Format "CTEXT text, id, col, row, width, height [, style]". Defines a centered static text control. DEFPUSHBUTTON - Format "DEFPUSHBUTTON text, id, col, row, width, height [, style]". Defines the default pushbutton for a dialog box. EDITTEXT - Format "EDITTEXT id, col, row, width, height [, style]". Defines an editable text control in a dialog box. The style parameter can be any combination of WS_TABSTOP, WS_GROUP, WS_VSCROLL, WS_HSCROLL, WS_BORDER and WS_DISABLED. Text is aligned based on ES_LEFT, ES_CENTER or ES_RIGHT. GROUPBOX - Format "GROUPBOX text, id, col, row, width, height [, style]". Draws a rectangle with a title at the top left around a group of other controls. ICON - Format "ICON text, id, col, row [, style]". Places an icon in the dialog box. The "text" parameter is the name of the icon as defined elsewhere in the .RC file with an ICON statement. The only allowed style is SS_ICON. LISTBOX - Format "LISTBOX id, col, row, width, height [, style]". Places a list box in the dialog box. An example of a list box is, if you run a Windows application and select "File Open..." from the menu bar, the box that appears with a list of the filenames available for opening. Possible values for "style" are any styles allowed in CreateWindow(). LTEXT - Format "LTEXT text, id, col, row, width, height [,style]". Defines a left-justified static text control. PUSHBUTTON - Format "PUSHBUTTON text, id, col, row, width, height [, style]". Defines a pushbutton for a dialog box. The allowed styles are WS_TABSTOP, WS_DISABLED and WS_GROUP. RADIOBUTTON - Format "RADIOBUTTON text, id, col, row, width, height [, style]". Defines a radio button in a dialog box. RTEXT - Format "RTEXT text, id, col, row, width, height [,style]". Defines a right-justified static text control. SCROLLBAR - Format "SCROLLBAR id, col, row, width, height [, style]". Defines a scroll bar within a dialog box. Here is an example of the DIALOG statement that could be used for showing a list of printers and letting the user select one. It includes a list box to hold the printer names and three buttons: OK, RESET and CANCEL. IDL_PRINT DIALOG LOADONCALL MOVEABLE DISCARDABLE 78, 40, 124, 58 CAPTION "Select a Printer" STYLE WS_OVERLAPPED | WS_DLGFRAME | WS_CAPTION | WS_POPUP BEGIN LISTBOX IDL_LIST, 32, 6, 60, 27, LBS_STANDARD |WS_HSCROLL |WS_BORDER DEFPUSHBUTTON "OK", IDL_OK, 4, 40, 37, 14, WS_GROUP PUSHBUTTON "Reset", IDL_RESET, 44, 40, 37, 14, WS_GROUP PUSHBUTTON "Cancel", IDL_CANCEL, 84, 40, 37, 14, WS_GROUP END That's all for now about dialog boxes. We'll continue next month with more resource types. If you don't like the format and have an idea for a better one, drop us a note. Programming Drag&Drop with Windows 3.1 by Andreas Furrer This article describes writing applications that uses Drag&Drop. At the end of this article is an example of an application that makes the use of Drag&Drop. The program is written in Turbo Pascal for Windows (1.0), but many of the things you'll learn in this article will port to other languages. A nice new feature of Windows 3.1 is Drag&Drop (D&D). With D&D you can use the File Manager to select files and drop them onto an application to perform some action on the files (e.g., print them). In Windows 3.1 there are a lot of applications that make use of D&D. For example, if you want to read a text file you can simply pick it up in File Manager and drop it onto the window or the icon for Notepad or you can print files by dropping them onto your Print Manager. You can also use D&D for your own applications. D&D is supported by the new SHELL.DLL. There are four procedures and one new message. The declarations in Pascal are: const wm_DropFiles = $0233; procedure DragAcceptFiles(Wnd: HWnd; Accept: Bool); external 'SHELL' index 9; function DragQueryFile(Drop: THandle; FileIndex: Word; FileName: PChar;MaxChars: Word): Word; external 'SHELL' index 11; function DragQueryPoint(Drop: THandle; var Pt: TPoint): Bool; external 'SHELL' index 13; procedure DragFinish(Drop: THandle); external 'SHELL' index 12; To use D&D with your application, you first have to register at least one Window of your application to accept dropped files. This will be done by: DragAcceptFiles(HWindow,true); Now this HWindow will receive wm_DropFiles message if some files are dropped onto it. If you want to undo the registration just pass false as the second parameter to the function above. This should always be done when your window is destroyed. If someone drags some files onto your window you will receive a wm_DropFiles message. The word parameter (wparam) of this message is a handle to a global data structure. This structure contains information about the dropped files and you have to use this handle for all Drag&Drop procedures. LParam is not used with this message. Now you can get information about the dragged files. You have to use the following two functions: DragQueryFile: function DragQueryFile(Drop: THandle; FileIndex: Word; FileName: PChar;MaxChars: Word): Word; external 'SHELL' index 11; With this function you will get the filename of one of the dragged files. You have to pass the handle of the D&D structure (received by wm_DropFiles), the index of the file (0 is the first), a buffer for the filename and the size of the buffer to this function. The function will copy the filename into the buffer and return the number of copied chars. To get the number of dropped files you can use $ffff as index. DragQueryPoint: function DragQueryPoint(Drop: THandle; var Pt: TPoint): Bool; external 'SHELL' index 13; With this function you can get the position of the cursor at the moment when the files were dropped. You have to pass the handle for the D&D structure (received by wm_DropFiles), and a variable of type TPoint to this function. The return value is true, if the files were dropped in the client area of the window, otherwise (for the non-client area) it is false. At the end of your D&D procedure you have to tell Windows to release the memory of the D&D data structure. This will be done with the DragFinish function. Again you have to pass the handle of the D&D structure to this function. A simple application for demonstrating D&D is a Trashcan. The accompanying code will implement a Trashcan which will delete all files and directories you dropped into its icon. See the TRASH.PAS file. After starting Trashcan, you can easily delete files and directories. Just select the files or directories in File Manager and drag them onto the icon of trashcan. If you have selected a hidden, read-only or a system file, you will be asked if you really want to delete it. To build Trashcan, you first have to open TRASH.RC with the resource workshop and save it as TRASH.RES in the .RES format. Now you can compile TRASH.PAS and you will get TRASH.EXE. A Custom Install Program: Part I Using DDE to Communicate with Program Manager By Pete Davis This is going to be a four part article on writing an Install program for Windows applications. I haven't completed the program yet so I don't even know exactly how it's going to turn out. My main problem at this point is that I really want to have a file compression algorithm for the files to be installed. The main problem is my laziness. I'm not really in the mood to write a unzip program, but since I'm having trouble coming up with alternatives, that may be my only possibility. This program is going to be loosely based on one I wrote in the past. I can't use any of that code because it is now the property of someone else, so I have to start from scratch. There are essentially three main sections which I will discuss separately. There's the part that runs last (which I'll be discussing first) which involves telling Program Manager to create our program group(s) and application icon(s). The second part reads and interprets a SETUP.INF file to get parameters of the installation, such as what files are to be installed, what disk they're on, whether or not they're executables, what is the default directory, etc. The third part is the previously mentioned decompression routines. (If anyone has a decompression algorithm they'd like to donate, that would be terrific.) The last article will tie all these parts together and make them all work together. One thing of extra interest will be that the decompression routines will be in a DLL. When I originally wrote my first install program, the UNZIP algorithm I used required a lot of memory and it was either make it a DLL or give it it's own data segment. I still haven't spent enough time with multiple data segment programs, so I stuck with the easy (or so I thought) method, the DLL. The first part I want to discuss is using DDE to communicate with Program Manager. This was the most challenging part for me the last time I wrote an Install program, so it seems to me that it would be the part that would be most interesting for a lot of people. My first few attempt at creating program groups were pathetic cludges. My main aim at the time was just to create the program group files myself and make the appropriate modifications to the PROGMAN.INI file. This turned out to be a little more difficult than I expected and I soon abandoned it. The next thought was to just create my own program group files and install them as part of the installation process. This was a workable solution but would not allow for installing the code in anything but the default directory. About the time I was mulling over the good and bad points of the last option, I came across a little snippet about using DDE to communicate with Program Manager. After a lot of reading and looking at source code from different sources I finally got a handle one it. This, incidentally, was my first attempt with DDE so it was doubly challenging. My first attempt at the DDE was itself a bit of a cludge. Instead of trying to follow all of the normal DDE protocols, I just tried to force my commands on Program Manager without the proper acknowledgements. (Ok, so I'm a little lazy.) This was only partially successful and I soon broke down and went the whole nine yards. From my experience with it, I have only this to say: Follow the protocol. Don't try to force DDE down some applications neck, 'cause it's gonna puke. Since this article doesn't discuss DDE in general, I'm not going to go in depth about variations in DDE. That will be discussed in a later article by me or someone else (hopefully!). The way DDE with Program Manager works is something like this. You put together a string of commands and place them in a globally allocated space. A typical Program Manager command is: [CreateGroup(My Group)] You then send a WM_DDE_EXECUTE command to Program Manager and pass it the handle of your globally allocated string. That's about all there is, in theory. In practice, there's a lot that needs to be done. The segment of DDE code provided with this issue is called PMDDE.C. This contains routines which will be called by the main program, so it isn't a runable module in itself. It can be included with your own programs, however. Additionally, since I haven't finished the entire program yet, there's no way to be sure that it all works. Well, that's just a little splash of real life. If it doesn't work when I'm done, then I'll just have to fix it and provide any fixes required. I debated whether to do this article now or wait until I had the whole program together, but I decided that even if there are mistakes, the algorithm itself is still valid, and the final product will work. The best way to handle a DDE conversation is to create a window that's sole purpose is to handle your DDE conversation. In our case, and in most, the window that handles the DDE conversation is not the main window and it is usually not a window in the sense that it's visible. It is simply the procedure which handles the DDE messages that we want. In our case we'll call this procedure the DDEWndProc. The creation of this window is handled in the main program, but I'll give you an idea of what the code looks like. /* This code is executed when the main windows procedure receives the WM_CREATE message wc is a WNDCLASS variable. hDDEProc is a static HWND */ wc.style = 0; wc.lpfnWndProc = DDEWndProc; wc.cbClsExtra = 0; wc.cbWndExtra = 0; wc.hInstance = hInstance; wc.hIcon = NULL; wc.hCursor = NULL; wc.hbrBackground = NULL; wc.lpszMenuName = NULL; wc.lpszClassName = "DDEWndProc"; RegisterClass(&wc); hDDEProc = CreateWindow("DDEWndProc", NULL, WS_CHILD, 0, 0, 0, 0 hWnd, NULL, hInstance, NULL); if (!hDDEProc) MessageBox(hWnd, "DDE Window won't come up.", "ERROR", MB_OK); That's all there is to creating this blank little window. The next thing on our list is to handle the actual DDE conversation. Under the WM_CREATE of our DDEWndProc procedure, we need to add two global atoms. These are the Application and Topic names that our conversation is supposed to deal with. When you start a DDE conversation and you want to contact a DDE server application (Program Manager in this case) so you need to use the Application and Topic. Essentially what you do is send a WM_DDE_INITIATE message with the application and topic as a parameter. (These are actually one parameter by passing the MAKELONG(Application, Topic) as a long in the message parameter. You also need to pass the handle for your DDEWndProc in this message so that Program Manager will know how to get back in touch with us. Notice that the SendMessage has a -1 for the first parameter. This tells Windows to essentially broadcast the message to all programs that are running. The DDEWndProc will handle several other messages. One of them is the WM_DDE_ACK message. This message is used to acknowledge responses from the DDE server (Program manager.) This part is not quite so intuitive as I learned. First of all, this part has to be broken up. If you're acknowledging the WM_DDE_INITIATE (which we sent first thing. Don't tell me you already forgot what I wrote in the last paragraph!) Ok, so here we are sitting around with nothing to do and BOOM, we get an acknowledgement from our WM_DDE_INITIATE. Well, it's about time. So the first thing we want to do is make sure we grab the handle of Program Manager. This is passed as the wParam of the WM_DDE_ACK message sent by Program Manager in reply to our WM_DDE_INITIATE message. With all of the other messages we send to Program Manager, we will now know exactly who to send them to and not have to broadcast all of our messages. At this point I'd like to mention one thing about DDE. There are two ways to send Windows messages. You can use the SendMessage or the PostMessage procedures. Both functions do the same thing except with SendMessage, the message is sent and execution stops until the receiver of the message has finished processing the message. With PostMessage, control returns to the calling program immediately. With DDE you use the SendMessage only for the WM_DDE_INITIATE message. For all other messages you use the PostMessage procedure. In our DDEWndProc we need to handle the WM_DDE_ACK message. This is sent by Program Manager in response to all of our messages. We're actually going to break that process into two parts, though. The first WM_DDE_ACK that we get is in response to our WM_DDE_INITIATE. When we get the acknowledgement we then have to make sure that Program Manager will handle our conversation. We also need to grab Program Manager's handle. Additionally, the lParam of each WM_DDE_ACK is probably going to have some data that it points to that we need to delete. In the WM_DDE_INITIATE response the handles for two atoms are sent back to us. In this case, they happen to be the same two atoms we sent, so we just delete them. In response to our WM_DDE_EXECUTE messages, we get a Global Memory handle that is also the same one we sent to Program Manager (you'll see this later) so we have to free it. That basically handles all the rough stuff. To send commands to Program Manager we need to use the GlobalAlloc command with the GMEM_DDESHARE option so that we can share the data with Program Manager. The data is actually just text strings that we pass to Program Manager to execute as commands. These are commands like CreateGroup, AddItem, etc.. The commands we'll use are: * CreateGroup(Group Name[, Group Path]) Where Group Name is the name of the Program Group you want to add to Program Manager. Group Path is optional and specifies the path of the group file. In our case, we'll let program manager decide where to put that. * AddItem(Program [, Program Name, IconPath, IconNum, X, Y, DefDir, HotKey, Minimize] Just adds an Program item to the group you've created. The Program is that Path and the Filename of the executable. Program Name is the name you want to give it under Program Manager. Those are the only two we're going to cover for now. The other messages we're going to handle is the WM_CREATE_PMGRP and WM_ADD_ITEM. These are custom messages that we're going to define in our .h file. The first is used to create the program group under Program Manager and the second is going to be create any items we're putting in the program group. The lParam of these messages is going to be a handle for Atoms that are going to have the names of the program group and the file names. We'll then create the entire string that we want like: "[CreateGroup(New Group)][ShowGroup(New Group)]" and pass this off to Program Manager with a WM_DDE_EXECUTE message. Notice that all commands are in brackets. Don't know why but just use 'em. That about covers the PMDDE.C. I might modify it before the fourth article in this series, but if I do I'll pass it along. Implementing a Linked List in the Global Heap By Mike Wallace The ability to implement a linked list is almost a requirement if a platform wants to get taken seriously. If you don't know what a linked list is, let me explain. Using an array to store data internally is fine if you have a good idea of how many items you'll need to store, which will determine the size of the array (which must be stated explicitly in your code prior to compiling). However, if you don't have a reasonable upper bound, you have two solutions: either make the array as large as possible and hope it always works, or allocate memory dynamically. The first solution isn't good enough. It usually means a lot of wasted memory, and in Windows, that's memory you can't afford to lose. The second solution is a bit more difficult to implement, but is the only way to go. By allocating memory dynamically (that is, at run-time), you only allocate exactly enough memory needed to hold your data. This is the method that produces a linked list, so called because the data is stored in a "list" of memory blocks (nodes), where each block holds an item of data plus another field giving the memory location of the next node in the "list", thus "linking" the data. I recently had to implement a linked list for a Windows program but could not find any good examples of how to do this, so I had to reason the problem out. It turned out to not be as difficult as I expected, but there are some things you need to keep in mind when implementing a linked list. Microsoft advises that when allocating a memory block, make it moveable and discardable. Why? Windows is more efficient if it can move your memory block around while the program is running in order to make the most of the available memory. However, a consequence of this is that you cannot use a pointer when linking two consecutive nodes in the list because Windows can (and will) move each node around in memory as it sees fit. So, I had to use a handle since that would guarantee the address stored in it (for the next node) would always be valid. The tricky part was that Windows requires a memory block to be locked when accessing a node by handle because that ensures the node won't be moved until you unlock the block. At the end of this article I've included the source code for a routine which allocates ten nodes in the global heap, stores in each node a number between 1 and 10 (the numbers are stored consecutively), then traverses the list and prints (to a file) the value stored in each node, and finally, retraverses the list and frees each node one at a time. Included with the Windows Programmer's Journal package is all the code and files needed to run the program. All of the files have a filename of "linklist", except the batch file which is run to compile the program, which is called "makelist.bat". The beginning of the function contains declarations for the variables needed to implement the linked list. The _listmarker structure is the structure of each node in the list. The LISTMARKER variable has to be a FAR pointer to the structure since the function uses the global heap. The LISTMARKER variables (tailPos, tempPos and headPos) are used to traverse the list. Finally, "fp" is a file pointer to the output file. After the function opens the output file for writing, it does a GlobalAlloc to allocate a block on the global heap for the first node. If "NULL" is returned, it means there was not enough room for the node of a size of FileMarker, so the function displays a message to that effect and returns to the calling routine. Otherwise, the allocated block is locked (so the block doesn't move while its fields are getting assigned), gets initialized and then gets unlocked. The "hMem" handle points to the first node for the duration of the function. This algorithm is repeated for each successive node, using tailPos to point to the current end of the list. The function then traverses the linked list, printing out the value of the "value" field to the output file. This is done by locking each node, performing a "fprintf" on the "value" field and then unlocking the node. The output file is then closed. Finally, the function traverses the list, freeing each node one at a time. This is done by locking each node, saving its handle to the next node, unlocking the current node and then freeing it. This algorithm is repeated until the list has been traversed. That is the entire algorithm. This is the first time I have written a linked list in Windows, so there may be more efficient methods of attaining the same ends. If you can find any, please send in your suggestions and we'll print them. void FAR PASCAL MakeList (HWND hWnd) { /* local variables */ short i; static HANDLE hMem, hMem2, hMem3; /* structure of each node in linked list */ typedef struct _listmarker { short value; HANDLE next; } ListMarker; /* declare a far pointer to the above structure */ typedef ListMarker FAR *LISTMARKER; LISTMARKER tailPos, tempPos, headPos; /* pointer to output file */ FILE *fp; /* Open output file for writing */ fp= fopen("data.out", "w"); /* Build initial linked list of the numbers 1 to 10 */ if((hMem= GlobalAlloc(GMEM_DISCARDABLE | GMEM_MOVEABLE, sizeof(ListMarker))) == NULL) { /* Not enough memory, so beep, show a message and return */ MessageBeep(0); MessageBox(hWnd, "Out of allocation memory!", "ERROR", MB_OK); return; } /* Lock the first node, save a value, set next to NULL and unlock */ tailPos= headPos= (LISTMARKER) GlobalLock(hMem); headPos->value= 1; headPos->next= NULL; GlobalUnlock(hMem); /* Allocate a node for each of the numbers between 2 and 10 and link */ for (i=2; i < 11; i++) { /* setup index lookup lists */ if((tailPos->next= GlobalAlloc(GMEM_DISCARDABLE | GMEM_MOVEABLE, sizeof(ListMarker))) == NULL) { MessageBeep(0); MessageBox(hWnd, "Out of allocation memory!", "ERROR", MB_OK); return; } /* If - End */ /* Lock the next node, save the value, and set its next to NULL */ hMem2= tailPos->next; tempPos= (LISTMARKER) GlobalLock(hMem2); tailPos= tempPos; tailPos->value= i; tailPos->next= NULL; GlobalUnlock(hMem2); } /* While - End */ /* Lock the 1st node and write out its "value" field */ tailPos= headPos= (LISTMARKER) GlobalLock(hMem); fprintf(fp, "%d\n", tailPos->value); /* Save the handle to the next node */ hMem2= tailPos->next; /* Unlock the 1st node */ GlobalUnlock(hMem); /* Go through list and print out "value" until no more nodes */ while (hMem2 != NULL) { /* Lock the next node and save to tailPos */ tempPos= (LISTMARKER) GlobalLock(hMem2); tailPos= tempPos; fprintf(fp, "%d\n", tailPos->value); /* Get the handle to the next node and then unlock the current one */ hMem2= tailPos->next; GlobalUnlock(hMem2); } /* While - End */ /* Close the output file */ fclose(fp); /* free nodes in the list */ tempPos= (LISTMARKER) GlobalLock(hMem); hMem2= tempPos->next; tempPos= (LISTMARKER) GlobalLock(tempPos->next); GlobalUnlock(hMem); GlobalFree(hMem); while(tempPos->next != NULL) { hMem3= tempPos->next; tempPos= (LISTMARKER) GlobalLock(tempPos->next); GlobalUnlock(hMem2); GlobalFree(hMem2); hMem2=hMem3; } GlobalUnlock(hMem2); GlobalFree(hMem2); return; } /* MakeList */ Book Reviews By Pete Davis Undocumented Windows: A Programmer's Guide to Reserved Microsoft Windows API Functions by Andrew Schulman, David Maxey, and Matt Peitrek Addison-Wesley Publishing Company ISBN 0-201-60834-0 Well, away with the formality and on to the book review. If you're comfortable with programming Windows, then I have only two words to you regarding this book: BUY IT! This is the one of the best references, not only for finding functions that Microsoft 'forgot' to tell us about, but it also gives an incredible amount of insight into how the internals of Windows operates. Not to take away from Maxey and Peitrek, but Schulman's fingerprints are all over this book. This book is very well organized. Each chapter is divided in a way that's easy to understand and covers specific topics. It's hard to know where to start with this book, it has it all. It has chapters on KERNEL, USER, GDI, and SYSTEM calls. It has a chapter on undocumented Windows messages. There are great chapters on how to disassemble and examine Windows executables. This is particularly useful for the true Windows hacker. The book also comes with a load of utilities for examining Windows executables. I have actually found several of these utilities useful simply for debugging my own code. Some of the utilities will tell you what undocumented calls a program is making. This is a neat little way to find out who's got an inside track at Microsoft. Of course, with the release of Undocumented Windows, many of these calls are going to be used more frequently. Microsoft's humor in naming some of these calls (e.g. BozosLiveHere and TabTheTextOutForWimps) are accented with the authors' humor. When discussing how a certain utility sometimes "decides that a function is undocumented when in fact it's documented. (It's sort of like one's coworker who every week thinks he's found a bug in the compiler)." The book is a joy to read just for the humor alone. Although there are a lot of functions listed (well over a hundred, I'd guesstimate), the true value of this book lies in its discussion of Windows and how Windows operates. There is more in this book on the internal operations of Windows than any ten books I've seen. He also discusses at length the politics at Microsoft regarding the undocumented functions. Well, I've talked about all the reasons that I like the book, but let's discuss it's usefulness. Is it useful? Well, for its in-depth discussion of Windows internals, yes. The functions themselves are scattered in a lot of different areas of programming. Some would be useful to some people while others would be useful to others. For example, someone working on a Windows debugger would be very interested in task queues and the like whereas a programmer of a painting package might be more interested in the GDI function calls. There are tons of functions and the documentation of each one is more complete than the documentation Microsoft provides for most of it's 'documented' functions. Schulman and Co. have done a fantastic job on this book and I don't think I could give it a higher recommendation. I look forward to his Undocumented NT (maybe? perhaps?). Last Page By Mike Wallace Well, it's happened. The first issue of Window's Programmer's Journal (official motto: Apply directly to infected areas) is done, and I feel good about it. Why? Because it's the first magazine I've seen that is fully devoted to Windows programming and it's more than just product reviews. Pete and I were hungry for something like WPJ but couldn't find anything that was really helpful, so we thought, "Let's do one ourselves." It's been fun so far, and hopefully we'll get lots of articles from ya'll so we can fill each issue with solutions to your Windows programming problems. If you think you have an idea for an article, send it in! If you just want to submit an outline for an article to see if we'd be interested before you write a full article, do it! The magazine can't last long without help from you people, and if you've done something cool in Windows, we want to hear about it! If you have any questions about Windows, ask! We're going to start a letters column as soon as we have enough letters to fill one, and if we can't answer your questions, we'll submit them to the rest of our readers to get an answer. We're not just doing this as part of our work-release program, we want to learn everything we can about programming in Windows, and I haven't seen any magazines that are as devoted to it as I'd like, and we're not looking for articles written by people with Ph.D.s - we'll take an article from anybody. Future issues will depend on it. Speaking of future issues, we have a few ideas about what you'll see soon. Pete's going to write an article about how to print under Windows 3.0 & 3.1, we'll continue our beginner's column, start a column on how to program C++ (written by me - since I don't know anything about C++, I seemed overly qualified to write a beginner's column on it), some product reviews of books and software, and just yesterday I bought a Windows NT workstation and Pete has the pre-release of NT, so we're going to tell you all about that and try to write some programs for it. Coming Soon! The WPJ BBS! By Jan. 1st (if we're lucky, and by the 5th if we're not quite so lucky), you can send your articles and letters directly to us. We also plan on putting the SIMTEL20 CD-ROM on it so you can download anything you want. It's a great CD full of stuff you never knew you needed but can't live without once you get it. We'll also be getting the CICA CD-ROM of Windows shareware and public domain software soon. See the "How to get in contact with us" section elsewhere in this issue for more info. If you're wondering about the point of this column, this is where I get to rant and rave about anything I'd like. If you don't want to read it, don't. You won't miss anything of earth-shattering importance. I'll try to make it interesting, but there's no telling what will happen here - you'll have to wait and see. If there's anything on your mind you want to talk about it, send me a note and if it sounds like it would be of interest to other readers, I'll write what I can about it. This is your forum as much as mine. One of my minors in school (Va. Tech, by the way - I graduated in '89 with a BS in Computer Science) was philosophy (the other was math - I knew you were wondering about that!), so just because I don't know anything about a subject won't stop me from writing about it. If there's anything you want to get off your chest, tell me about it. I'm always looking for a good discussion about anything. That's the first issue. Hope you liked it; hope we're around for awhile. This could be a lot of fun, and we want you to join us. Until next month, may you look like the late Totie Fields! Getting in touch with us: Right now there are only four ways to get in touch with us. If you have access to the Internet or BITNET, you can get in touch with us at: HJ647C at GWUVM.GWU.EDU -or- HJ647C at GWUVM.BITNET (both Pete) CompuServe: 71141,2071 (Mike) WPJ BBS (703) 503-3021 You can also send paper mail to: Windows Programmer's Journal 9436 Mirror Pond Drive Fairfax, VA 22032 U.S.A. Also, around January 1st, we'll be setting up a BBS specifically to support the WPJ, but we'll also be offering the SIMTEL20 CD-ROM for downloads. The SIMTEL20 system is one of the largest sources of public domain and shareware software. We'll also be adding more CDs later as we can afford it. Anyway, the Windows Programmer's Journal BBS can be reached at: (703) 503-3021. You can get in touch with either Mike or Pete at this number. The BBS is going to be relatively new, so don't be surprised if it's a little buggy in the beginning. Right now it's only 2400 baud as my 9600 baud modem died on me, but in the first month or two you can expect it to go up to 14,400. You can also expect to see a Fido-net node address by the second issue.