BUG: 16-bit setup.exe issues

[tschweikle at FIDUCIA.de]

>tschweikle at FIDUCIA.de wrote:
>>
>> stephen waters wrote:
>>
>> > yes, that would have been my first thought except that it worked fine
>> > off of a WinNT 4.0 server whereas it did not work on samba in the exact
>> > same directory structure. on the samba box there is an error that says:
>> >
>> > "Cannot find file \\server\public\\temp\setup.dll. check to ensure the
>> > path and filename are correct and all libraries are available."
>> >
>> > notice the second set of \\ ?  that's where long_dir_name should have
>> > been. if i simply move the temp dir up one level to \\server\public\temp
>> > then it works b/c there are no longer any long dir names in the UNC
>> > path.
>> >
>> > i also notice that there's an error in the logfile, perhaps unrelated:
>> > [1999/09/20 12:47:32, 1] smbd/nttrans.c:call_nt_transact_ioctl(2387)
>> >   call_nt_transact_ioctl: currently not implemented
>> >
>> >
>> > -stephen
>> >
>> > Allen Reese wrote:
>> >>
>> >> Some versions of InstallShield, 5 IIRC, have problems launching setup off
>> >> of a UNC path.
>> >>
>> >> I was writing InstallShield installers for a while and ran into a bug
>> >> where some 16bit setup would fail off any UNC path because the
>> >> installshield code tries to get the drive letter of the UNC path and
>> >> fails.  I never had 8.3 related problems, but I ran into a lot of problems
>> >> if the drive I was trying to run the installers from was not mapped.  And
>> >> this was only with 16bit compatible installers.  If I did a 32bit only
>> >> installer, then it would install just fine via a UNC path, say
>> >> \\server\share\setup.exe  whereas, if I built the same installer but with
>> >> 16bit setuport, it wouldn't install from the UNC path under 95 unless I
>> >> mapped the drive.  ;)
>> >>
>> >> Check if the installer is an InstallShield installer, and if so that may
>> >> be part of the problem.  If you look in their KB any 16bit IS5 installers
>> >> have lots of UNC problems.  ;)
>> >>
>> >> But then all of this was 1-2 years ago.
>> >>
>> >> Allen Reese
>> >> Senior Software Engineer
>> >> Driversoft, Inc.
>> >> allen at driversoft.com
>> >>
>> >> On Tue, 21 Sep 1999, Stephen Waters wrote:
>> >>
>> >> > here's the scoop:
>> >> >
>> >> > samba 2.0.5a on linux 2.2.12+raidpatch.
>> >> >
>> >> > everything seems to work great except that 16-bit setup.exe files have
>> >> > trouble finding requisite .dlls in the current working directory if
>> >> > there are any non-8.3-compliant directories in the path.
>> >> >
>> >> > e.g.,
>> >> >
>> >> > 2 files, setup.exe setup.dll, in \\server\public\long_dir_name\temp\
>> >> > if execute setup.exe it will give an error saying that it cannot find
>> >> > setup.dll; however, if i move \\server\public\long_dir_name\temp\ to
>> >> > \\server\public\temp\ setup.exe finds setup.dll just fine.
>> >> >
>> >> > our Windows NT 4.0 server did not have any problems with this setup so i
>> >> > thought either 1) there is a bug in samba or 2) the client is stupid and
>> >> > NT has a workaround. i vote for [2], but i'd really like to see a
>> >> > workaround.
>> >> >
>> >> > i changed default case to upper when trying to figure out what was
>> >> > wrong.
>> >> >
>> >> >
>> >> > -stephen waters
>> >> > internal sysadmin
>> >> > amicus, inc.
>> >> >
>>
>> There is a workaround for this sort of problem:
>>
>> make dafault case lower/upper an set samba to ignore case (don't preserve
>> case on the server):
>>
>>         preserve case = No
>>         short preserve case = No
>>         mangled names = No
>>
>
> out of curiousity, is this how NT handles this sort of thing?

Had this problem with IBM-LAN-Server. Traced the network messages.
Yes! NT handles it this way. But only for DOS and WfW clients.
Others (OS/2, WinNT, smbclient) get the long names --- making it
clear why only old 16-bit applications have problems with new
evironments like Win9x/NT.

OS/2 is a bit more difficult, because it hides all this from 16-bit
applications. They will only see short names, built the way given
by the workaround. But this is local to every 16-bit application with
OS/2. Why Win9x/NT didn't implement it this way I do not know - think
they didn't like the additional overhead/work that had to be done...

--