comp.lang.idl-pvwave archive - RDF feed
type: channel
description: Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
items: IDL for Windows NT??
items: Re: IDL for Windows NT

IDL for Windows NT??
type: item
description: 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
creator: harmer
date: 1994-09-16T20:01:38-00:00

Re: IDL for Windows NT
type: item
description: 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
creator: thompson
date: 1995-03-07T15:43:21-00:00

Re: IDL for Windows NT
type: item
description: 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) t…
creator: rcampbell
date: 1995-03-09T14:22:40-00:00