1. Translator issue with Watcom
The Watcom C compiler, at some point in history, wasn't supporting the creation
of long file names under Windows. This is documented in e2c.htm. I don't know if
this is obsolete. Does anyone know?
As a result, it would seem logical that the translator _always_ uses truncated
.c/.obj file names when using Watcom - assuming the right option isn't
implemented yet in the compiler. Yet, the generated emake.bat and objfiles.lnk
files have references to the complete file names.
win32lib now has files whose names are more than 8 character long, like
w32memory.ew (9). Hand editing the above files helps remove error messages. Yet,
the compilation process outputs complete names - hence they have been retained at
some point -, and the resulting .exe hangs even when it is as skeletal a program
as you can imagine. Creating a simple window doesn't work as a .exe file. Neither
compile nor link errors are reported (again after hand editing).
A workaround could be to change all long names to short enough ones -
w32memory.ew -> w32mem.ew. But it also means program names must be short too. It
seems ludicrous to me to do that when Windows allows long file names precisely so
that they can be more self-explanatory.
What to do?
CChris
2. Re: Translator issue with Watcom
CChris wrote:
> The Watcom C compiler, at some point in history, wasn't supporting the
> creation
> of long file names under Windows. This is documented in e2c.htm. I don't know
> if this is obsolete. Does anyone know?
That's only true on DOS.
Only the DOS version of the Translator (ec.exe) is affected by this,
not the Windows version. (With some minor effort we could probably
build ec.exe as a Windows console program and eliminate this problem,
even on DOS).
> As a result, it would seem logical that the translator _always_ uses truncated
> .c/.obj file names when using Watcom - assuming the right option isn't
> implemented
> yet in the compiler. Yet, the generated emake.bat and objfiles.lnk files have
> references to the complete file names.
> win32lib now has files whose names are more than 8 character long,
No problem. You would use the *Windows* version of the
Translator (ecw.exe) on anything involving Win32Lib.
> like w32memory.ew
> (9). Hand editing the above files helps remove error messages. Yet, the
> compilation
> process outputs complete names - hence they have been retained at some point
> -, and the resulting .exe hangs even when it is as skeletal a program as you
> can imagine. Creating a simple window doesn't work as a .exe file. Neither
> compile
> nor link errors are reported (again after hand editing).
>
> A workaround could be to change all long names to short enough ones -
> w32memory.ew
> -> w32mem.ew. But it also means program names must be short too. It seems
> ludicrous to me to do that when Windows allows long file names precisely so
> that they can be more self-explanatory.
>
> What to do?
It sounds like you accidentally ran ec.exe (DOS) on
a *Windows* program. Use ecw.exe
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Translator issue with Watcom
Robert Craig wrote:
>
> CChris wrote:
> > The Watcom C compiler, at some point in history, wasn't supporting the
> > creation
> > of long file names under Windows. This is documented in e2c.htm. I don't
> > know
> > if this is obsolete. Does anyone know?
>
> That's only true on DOS.
> Only the DOS version of the Translator (ec.exe) is affected by this,
> not the Windows version. (With some minor effort we could probably
> build ec.exe as a Windows console program and eliminate this problem,
> even on DOS).
>
> > As a result, it would seem logical that the translator _always_ uses
> > truncated
> > .c/.obj file names when using Watcom - assuming the right option isn't
> > implemented
> > yet in the compiler. Yet, the generated emake.bat and objfiles.lnk files
> > have
> > references to the complete file names.
>
> > win32lib now has files whose names are more than 8 character long,
>
> No problem. You would use the *Windows* version of the
> Translator (ecw.exe) on anything involving Win32Lib.
>
> > like w32memory.ew
> > (9). Hand editing the above files helps remove error messages. Yet, the
> > compilation
> > process outputs complete names - hence they have been retained at some point
> > -, and the resulting .exe hangs even when it is as skeletal a program as you
> > can imagine. Creating a simple window doesn't work as a .exe file. Neither
> > compile
> > nor link errors are reported (again after hand editing).
> >
> > A workaround could be to change all long names to short enough ones -
> > w32memory.ew
> > -> w32mem.ew. But it also means program names must be short too. It seems
> > ludicrous to me to do that when Windows allows long file names precisely so
> > that they can be more self-explanatory.
> >
> > What to do?
>
> It sounds like you accidentally ran ec.exe (DOS) on
> a *Windows* program. Use ecw.exe
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Just about right.
I had never used the Translator before (I write my C myself when I want
something blazing fast), and the documentation mentions very prominently ec.exe.
ecw.exe is mentioned only in relation with the MSC++ compiler or some specific
command line options. So I think there is stil something to fix in the
documentation - a far less serious issue of course!
Thanks. The problem had been submitted to me by a user, and that's how I was
drawn into this trap.
CChris
4. Re: Translator issue with Watcom
Robert Craig wrote:
> It sounds like you accidentally ran ec.exe (DOS) on
> a *Windows* program. Use ecw.exe
Would it make sense to modify ec to issue a warning suggesting that ecw might be
more appropriate when it encounters include dll.e?
Regards,
Pete
5. Re: Translator issue with Watcom
Pete Lomax wrote:
>
> Robert Craig wrote:
> > It sounds like you accidentally ran ec.exe (DOS) on
> > a *Windows* program. Use ecw.exe
>
> Would it make sense to modify ec to issue a warning suggesting that ecw might
> be more appropriate when it encounters include dll.e?
The 'right' way to do it is probably to allow any of the translators to
cross-translate. I think that it shouldn't be too difficult. Basically,
you'd probably have to wrap platform() so that its return value could
be overridden by a command line switch. That way, you could use ecw.exe
to translate dos apps by:
> ecw -dos myapp.ex
This would also be conducive to porting to other platforms. For example,
I'd imagine that a port to OSX would probably be done best by starting with
a BSD translation of the front end. And to do so, you wouldn't need to
have access to a BSD box, just any other supported platform.
Someone should submit an enhancement request.
Matt
