IDL for Windows NT?? [message #2786] |
Fri, 16 September 1994 13:01  |
harmer
Messages: 8 Registered: April 1994
|
Junior Member |
|
|
Hi
Does anybody out there known where I can get a Demo version
of IDL for Windows NT. We are considering getting away from 16 bits
on to a REAL 32 bit operating system, and I want to try it out.
Mark
|
|
|
Re: IDL for Windows NT [message #3659 is a reply to message #2786] |
Tue, 07 March 1995 07:43   |
thompson
Messages: 584 Registered: August 1991
|
Senior Member |
|
|
rcampbell@ssl.msfc.nasa.gov (Richard Campbell) writes:
> If anyone is planning on porting their IDL code from VMX or UNIX to
> Windows NT be aware that IDL for Windows NT does not support long filenames
> even though the operating system does support them. You will have to change
> all the .PRO files and all references to them to conform to the 8.3
^^^^^^^^^^^^^^^^^^^^^^^^^^
> convention. I have also heard that version 4 of IDL for NT will have the
> same limitation.
> rcampbell@ssl.msfc.nasa.gov
I have no experience with Windows NT, but the last time I used IDL for Windows,
I was able to use routine names longer than eight characters, so long as they
were stored in files whose names used the first eight characters of the routine
name. Thus, if I had a routine named COMBINE_COLORS, IDL would be able to find
it so long as it was stored in a file called COMBINE_.PRO somewhere in !PATH.
Also, if I had a routine called COMBINE_VEL, then it would also have to be in
that same file for IDL to find it. Probably, IDL for Windows NT acts the same
way.
Similarly, if I wish to open a file, I can open it with a filename longer than
eight characters, and only the first eight will be paid attention to.
Hence, I agree with the statement that the filenames have to be converted to
the 8.3 convention, but I disagree with the statement that all references to
these files need to follow that convention. You don't have to rename your
procedures. This is a common misconception about IDL for Windows.
Bill
|
|
|
Re: IDL for Windows NT [message #3783 is a reply to message #3659] |
Thu, 09 March 1995 06:22  |
rcampbell
Messages: 2 Registered: March 1995
|
Junior Member |
|
|
In article <3jhuup$8er@post.gsfc.nasa.gov>, thompson@orpheus.nascom.nasa.gov (William Thompson) writes:
> rcampbell@ssl.msfc.nasa.gov (Richard Campbell) writes:
>
>> If anyone is planning on porting their IDL code from VMX or UNIX to
>> Windows NT be aware that IDL for Windows NT does not support long filenames
>> even though the operating system does support them. You will have to change
>> all the .PRO files and all references to them to conform to the 8.3
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> convention. I have also heard that version 4 of IDL for NT will have the
>> same limitation.
>
>> rcampbell@ssl.msfc.nasa.gov
>
> I have no experience with Windows NT, but the last time I used IDL for Windows,
> I was able to use routine names longer than eight characters, so long as they
> were stored in files whose names used the first eight characters of the routine
> name. Thus, if I had a routine named COMBINE_COLORS, IDL would be able to find
> it so long as it was stored in a file called COMBINE_.PRO somewhere in !PATH.
> Also, if I had a routine called COMBINE_VEL, then it would also have to be in
> that same file for IDL to find it. Probably, IDL for Windows NT acts the same
> way.
>
> Similarly, if I wish to open a file, I can open it with a filename longer than
> eight characters, and only the first eight will be paid attention to.
>
> Hence, I agree with the statement that the filenames have to be converted to
> the 8.3 convention, but I disagree with the statement that all references to
> these files need to follow that convention. You don't have to rename your
> procedures. This is a common misconception about IDL for Windows.
>
> Bill
Thank you for your reply. I tried opening 8.3 named files using longer
filenames and longer file extensions and IDL for Windows NT works the same as
IDL for Windows just as you suspected. There will be much less impact on my
port from the VAX to Windows NT than I thought at first. The only problem is
with files (source code and data) that are not unique in the first 8
characters.
Richard
|
|
|