Differences in Windows Nt and Windows 3.1 apis?

Differences in Windows Nt and Windows 3.1 apis?

Post by Bob Zimmerm » Sun, 18 Dec 1994 06:43:33



I just picked up a book call Win32 AIP Desktop Reference by McCord... Are
there alot of differences between Win3.1 and Win32 (nt)...

Is there anything major in Win 3.1 that plain won't work in Win 32 or vice
versa...

Thanks... I would greatly appreciate replies via email as sometimes this
bandwith gets really busy. Thanks

--------------------------------------------------
    Bob Zimmerman

    www  : http://www.mcs.com/~bobzim/home.html
--------------------------------------------------

 
 
 

Differences in Windows Nt and Windows 3.1 apis?

Post by Lucien Ci » Mon, 19 Dec 1994 12:46:50


: I just picked up a book call Win32 AIP Desktop Reference by McCord... Are
: there alot of differences between Win3.1 and Win32 (nt)...

: Is there anything major in Win 3.1 that plain won't work in Win 32 or vice
: versa...

: Thanks... I would greatly appreciate replies via email as sometimes this
: bandwith gets really busy. Thanks

Oh. I know about this! I have been porting WinOne to Windows NT. There
are so many things that donot work, its hard to think of a place to start!
Most of the API functions are there, some have been removed. Handles are
now all void* and not unsigned int. That alone causes lots of problems.
Messages are now packed differently, since wParam is 32 bits. The nice
thing is that the 32 bit versions of DLL's work (eg. MMSYSTEM etc).

Not to forget, that any assembler, with not work. Any int 21 calls are
a worry. True multitasking can also throw some programs, that expect things
to happen in some order. The complexity of Win32 adds to the porting
problem. For example, long file names, exception handling, multi-threading
etc. Separate address spaces for each process can cause problems, especially,
if you are used to passing around memory handles to other tasks. The list
just goes on.....

I also had problems with bugs I found in Borland's 4.02 Run Time Library,
the 32 bit compiler (which generated incorrect code), the 32 bit optimiser
(which consistantly produced a mal-functioning executable), etc... See,
alt.comp.ms-windows.programming.tools (or something like that) for a more
detailed description of these bugs.

You may be interested to know, that I had to modify, just about every
file, that goes into making up WinOne. If only I knew what I was in for,
I would have given it a miss.

At least now that it is done, I can smile again :-)

___________________________________________________________________________
                                 _                     __
Lucien Cinc                     - - /, /,            ,-||-,
Author of WinOne                  )/ )/ )  '        ('|||  )
Super Command Line Shell v5.5     )__)__) \\ \\/\\ (( |||--)) \\/\\  _-_
     for Windows 3.1             ~)__)__) || || || (( |||--)) || || || \\

                                 /-_/-_/  \\ \\ \\   -____-   \\ \\ \\,/
Available from CICA :-
   ftp.cica.indiana.edu:/pub/pc/win3/util/w_one49a.zip and w_one49b.zip

 
 
 

Differences in Windows Nt and Windows 3.1 apis?

Post by Chris Marrio » Tue, 20 Dec 1994 22:24:20




Quote:>Oh. I know about this! I have been porting WinOne to Windows NT. There
>are so many things that donot work, its hard to think of a place to start!
>Most of the API functions are there, some have been removed. Handles are
>now all void* and not unsigned int. That alone causes lots of problems.
>Messages are now packed differently, since wParam is 32 bits. The nice
>thing is that the 32 bit versions of DLL's work (eg. MMSYSTEM etc).

>Not to forget, that any assembler, with not work. Any int 21 calls are
>a worry. True multitasking can also throw some programs, that expect things
>to happen in some order. The complexity of Win32 adds to the porting
>problem. For example, long file names, exception handling, multi-threading
>etc. Separate address spaces for each process can cause problems, especially,
>if you are used to passing around memory handles to other tasks. The list
>just goes on.....

>I also had problems with bugs I found in Borland's 4.02 Run Time Library,
>the 32 bit compiler (which generated incorrect code), the 32 bit optimiser
>(which consistantly produced a mal-functioning executable), etc... See,
>alt.comp.ms-windows.programming.tools (or something like that) for a more
>detailed description of these bugs.

>You may be interested to know, that I had to modify, just about every
>file, that goes into making up WinOne. If only I knew what I was in for,
>I would have given it a miss.

I'm interested to hear about your experiences. I recently ported my 70k line
astronomy program "SkyMap" to Win32. The ENTIRE process - from copying the
files into a new directory to having a fully working Win32 executable -
took me 90 minutes. I'm quite serious about that. I started at 2pm and had
a working 32-bit program by 3:30pm.

A few points:

1. I have ALWAYS used "STRICT" in my programs. This makes all HANDLES into
   distinct pointer types. Getting a program to build "cleanly" with STRICT
   defined is the essential first step in porting to 32-bits.

2. My program was LARGE model anyway - not a single FAR or NEAR in the whole
   thing. This makes moving to the flat memory model of Win32 a lot easier.

3. SkyMap is an MFC program. MFC hides all the parameter-packing differences
   from you. This again makes porting a lot easier.

4. I use Microsoft Visual C++ 2.0. This seems to be a MUCH better 32-bit
   compiler than Borland! No problems at all with bugs so far!

The only changes I had to make were:

1. Make sure that all structures which referenced external data files
   correctly used "short" when referring to 16-bit integers, since of
   course "int" is 32-bits in Win32.

2. Remove all obsolete keywords like "huge" and "export".

I was pleasantly surprised by what a painless process it was. I can only
reiterate the fact that having a "correctly written" *16-bit* program is
the VITAL first step in the process!

Chris
--
--------------------------------------------------------------------------
| Chris Marriott, Warrington, UK      | Author of SkyMap v2 shareware    |

|      Author member of Association of Shareware Professionals (ASP)     |
--------------------------------------------------------------------------

 
 
 

Differences in Windows Nt and Windows 3.1 apis?

Post by David Braba » Thu, 22 Dec 1994 00:55:42


Quote:>I'm interested to hear about your experiences. I recently ported my 70k line
>astronomy program "SkyMap" to Win32. The ENTIRE process - from copying the
>files into a new directory to having a fully working Win32 executable -
>took me 90 minutes.

[Deleted]

I've successfully ported a +/- 20.000 lines program in less than 45
minutes. The compiler used was VC++ 2.0. This was my first attempt
to compile a program using this compiler (just out of the box).
Like Chris, I always define STRICT in my programs and I use the
large model everywhere.
The sources compiled was a combination of C/C++ files.

David

     +---------------------------+-----------------------------------+

     | SIEMENS-NIXDORF,          | Phone  : +32 41 201 609           |
     | Centre Software de Liege, | FAX    : +32 41 201 642           |
     | 2, rue des Fories,        +-----------------------------------+
     | 4020 Liege, Belgium.      |     #include "disclaim.hpp"       |
     +---------------------------+-----------------------------------+
      The time for politic and religion has gone. Here comes the time
      for science and spirituality. (A.C. Clarke)

 
 
 

Differences in Windows Nt and Windows 3.1 apis?

Post by Kent To » Thu, 22 Dec 1994 08:42:13


|> I'm interested to hear about your experiences. I recently ported my 70k line
|> astronomy program "SkyMap" to Win32. The ENTIRE process - from copying the
|> files into a new directory to having a fully working Win32 executable -
|> took me 90 minutes. I'm quite serious about that. I started at 2pm and had
|> a working 32-bit program by 3:30pm.

As another example of porting Win16 program to Win32, I spent lots of time
on it. I admit that a part of it was devoted to reorganizing the structure
of the program and enhancements, but besides that, from my perspective
the port is not easy at all.

|> A few points:
|>
|> 1. I have ALWAYS used "STRICT" in my programs. This makes all HANDLES into
|>    distinct pointer types. Getting a program to build "cleanly" with STRICT
|>    defined is the essential first step in porting to 32-bits.

I use STRICT too.

|> 2. My program was LARGE model anyway - not a single FAR or NEAR in the whole
|>    thing. This makes moving to the flat memory model of Win32 a lot easier.

Me too.

|> 3. SkyMap is an MFC program. MFC hides all the parameter-packing differences
|>    from you. This again makes porting a lot easier.

Mine is a native API program. But no big deal here to change the WM_COMMAND
and EM_SETCURSEL param packing.

|> 4. I use Microsoft Visual C++ 2.0. This seems to be a MUCH better 32-bit
|>    compiler than Borland! No problems at all with bugs so far!

Me too.

|> The only changes I had to make were:
|>
|> 1. Make sure that all structures which referenced external data files
|>    correctly used "short" when referring to 16-bit integers, since of
|>    course "int" is 32-bits in Win32.

I didn't do this because no plan to support cross platform consistent
doc.

|> 2. Remove all obsolete keywords like "huge" and "export".

Did you remove "FAR"? I did.

|> I was pleasantly surprised by what a painless process it was. I can only
|> reiterate the fact that having a "correctly written" *16-bit* program is
|> the VITAL first step in the process!

OK, here is my turn,

- File operations

        OpenFile()    ===>   CreateFile()
        close()       ===>   CloseHandle()
       _lread()       ===>   ReadFile()
        ...

- Directory and volume operations,

        rmdir()       ===>   RemoveDirectory()
        mkdir()       ===>   CreateDirectory()
        getdiskfree() ===>   GetFreeSpace() ?

  It's not just a matter of changing function name. For example, GetFreeSpace()
  takes the root dir as argument rather than a drive number.

- Support security.

- Support long filenames.

- I used to manipulate INI files with my own routines to support operations
  like adding a new entry with an existing key. This apparently doesn't
  work if the INI file is mapped to the registry. Considering the fact
  that INI files are not recommended in NT, I switched back to the API
  functions to manipulate INI files and minimized the use of them in
  my program. In fact, my program doesn't use INI files at all, due to
  the nature of it, I still need to support this concept.

- The registration database has been replaced with a more complicated
  registry. Lots of work here.

- The HFILE handle return by LZOpenFile() no longer works with _lwrite()
  and etc. This is a subtle change from from Win16.

- The lang ID and character set ID in the resource statement used to
  be UINT's. Now they are WORD's. This is a subtle change.

- Toolhelp.dll no longer exists and even if it were, it wouldn't be
  recommended. This means any one of you using TERMWAIT has to switch
  to spawn, or if you prefer a native version like me, to CreateProcess()
  and CreateThread().

--

Freeman Installer (WWW)--->http://www.arch.su.edu.au/~tongk/0.html
Freeman Installer (ftp)--->ftp.arch.su.edu.au   /pub/tongk/finst152.zip
Key Center of Design Computing, Sydney University

 
 
 

1. Wanted: Windows installer for Windows 3.1/Windows NT

Hi,

I'm looking for an installation generator for Windows 3.1/Windows NT,
either public domain or not. Has anyone heard of a good one?

Thanks,

-- Nitsan Seniak
--

------------------------------------------------------------------------------

ILOG S.A.                               tel: +33 1 46 63 66 66
2 Avenue Gallieni, BP 85                fax: +33 1 46 63 15 82
94253 Gentilly Cedex                    url: http://www.ilog.fr/
FRANCE                                  or   http://www.ilog.com

2. Outlook/Exchange Help

3. Having Trouble Porting from Windows 3.1 to Windows NT

4. Windows 95 File system locking?

5. inp & outp in windows 3.1 and windows Nt

6. Formating between lower case and upper case..A puzzle

7. How to view a Window NT hlp-file with Window 3.1?

8. Help: Windows 3.1 Application on Windows NT

9. inp & outp in windows 3.1 and windows Nt

10. DLL differences for Windows 95 and Windows NT

11. Windows 3.1 functions not in Win32 API

12. Sounding WAV files using Windows 3.1 API