Search In
• More options...
Find results that contain...
Find results in...

# To Source Port coders...

## Recommended Posts

This is little bug report which the following source ports all have in common.
PrBoom
CSDoom
Doom3D
Doom4Win
EDGE
Eternity
Legacy
Lsdldoom
GLBoom
Vavoom
Windoom
ZDaemon
ZDoomGL

I'm posting it here because there are too many involved to go around individually posting in their forums (Yes, I am a lazy git)

Bug: using the external file commands with spaces in the name or path usually kill your ports
For example:
or

I know that in the old days (with DOS) this was never a problem, but these days more and more people have directory names with spaces(especially people who have never used MSDOS).

You should at least allow the option of enclosing the name and path in quotation marks, since that seems to be standard practise these days in the world of Windoze for dealing with this problem. :-)

I found only 2 ports that allow this : Zdoom and Doomsday (well done to these ports coders!)

that's just the way it works with win98, if you want spaces in your pathname use the run box and put "s around your command

Hooray! Doomsday/Dlaunch rules!

Liam the Bard said:

that's just the way it works with win98, if you want spaces in your pathname use the run box and put "s around your command

Either I don't understand you or you don't understand me, but what I'm trying to say is that I've only found 2 ports that allow the option of using "" around the commands in question.

Why don't you try your idea with, say Edge for example, and see what happens ;-)

Lobo said:

Either I don't understand you or you don't understand me, but what I'm trying to say is that I've only found 2 ports that allow the option of using "" around the commands in question.

Maybe you should have said that in your very first post?

Lobo said:

This is little bug report which the following source ports all have in common.
PrBoom
CSDoom
Doom3D
Doom4Win
EDGE
Eternity
Legacy
Lsdldoom
GLBoom
Vavoom
Windoom
ZDaemon
ZDoomGL

I'm posting it here because there are too many involved to go around individually posting in their forums (Yes, I am a lazy git)

Bug: using the external file commands with spaces in the name or path usually kill your ports
For example:
or

I know that in the old days (with DOS) this was never a problem, but these days more and more people have directory names with spaces(especially people who have never used MSDOS).

You should at least allow the option of enclosing the name and path in quotation marks, since that seems to be standard practise these days in the world of Windoze for dealing with this problem. :-)

I found only 2 ports that allow this : Zdoom and Doomsday (well done to these ports coders!)

you want it? CODE IT YOURSELF. shouldn't be too hard. the source port makers have done rediculous amounts of work to make their ports what they are. in fact if it weren't for them, we'd all still be using doom in dos with 8.3 filenames. be a little appreciative, and if it really bothers you, rename your paths so they don't have spaces in them.

esayeek said:

you want it? CODE IT YOURSELF. shouldn't be too hard. the source port makers have done rediculous amounts of work to make their ports what they are. in fact if it weren't for them, we'd all still be using doom in dos with 8.3 filenames. be a little appreciative, and if it really bothers you, rename your paths so they don't have spaces in them.

Jesus! This is the last time I report a bug!!

Stupid me, I thought programmers were interested in knowing about bugs in their programs, but it seems I was completely wrong.

boris said:

Maybe you should have said that in your very first post?

I thought I did! :-)

Lobo said:

You should at least allow the option of enclosing the name and path in quotation marks, since that seems to be standard practise these days in the world of Windoze for dealing with this problem. :-)

I found only 2 ports that allow this : Zdoom and Doomsday (well done to these ports coders!)

Lobo said:

Jesus! This is the last time I report a bug!!

Stupid me, I thought programmers were interested in knowing about bugs in their programs, but it seems I was completely wrong.

a feature is not a bug. and because doom was originally under dos and used 8.3 filenames, this is a feature request. you also have a very "holyier-than-thou" attitude when you post a lump comment for about a billion source ports and expect the coders of them all to flock to doomworld to read your crap.

btw: when i discovered that boom didnt support LFNs (even when compiled properly with lfn support under DJGPP), i renamed the .wad i needed to play with an lfn. take a hint.

esayeek said:

a feature is not a bug. and because doom was originally under dos and used 8.3 filenames, this is a feature request.

you also have a very "holyier-than-thou" attitude when you post a lump comment for about a billion source ports and expect the coders of them all to flock to doomworld to read your crap.

I'm very sorry that it came across that way: it wasn't my intention.

BTW I advise you to hit the IGNORE link so that my "crap" doesn't bother you in the future.

when i discovered that boom didnt support LFNs (even when compiled properly with lfn support under DJGPP), i renamed the .wad i needed to play with an lfn. take a hint.

Despite playing Doom and its ports for several years, I never even noticed this problem until I started coding a front end for Edge. Because I was a MS-DOS user I have the habit of NEVER using spaces in my directory and file names.

However, there are more and more PC users who have never seen MSDOS, and have the nasty habit of using long, space-filled names in windows. These are the people I was thinking of, not the old school Doomers.

now you make me feel srry :(

try this: create a response file with only the commands you want to run in it, like

-file directory with a space in it\wad with a space in it.wad -skill 4 -warp 23

then run
noncompliantsourceport @responsefile

try with quotes around the filename too.

it probably won't work, but it just might.

do you have the ability/knowledge to compile any of your source ports? i could probably find a fix and just send it to you and you would replace the proper lines in the proper file and then compile.

poke an email at the maintainers of csdoom and zdoomgl and zdaemon: because zdoom supports this, and they are zdoom spawn, all they have to do is incorporate the proper stuff from zdoom (which they should have no problem finding).

i will poke around prboom and try to find a fix, and send it over to the folks at prboom and prglboom if i can.

the rest of these source ports: i have never worked with their code, and i am not sure if they are maintained these days. some of them i know for a fact arent.

esayeek said:
a feature is not a bug. and because doom was originally under dos and used 8.3 filenames, this is a feature request.

I disagree; if you produce a program for Win32 or Linux that doesn't support the normal filenames allowed in th OS then that's a bug. And that includes spaces. Programs that only support 8.3 filenames deserve to be publically humiliated, and programmers who can't cope with that deserve to be punished by being forced to write DOS TSRs for the rest of their natural lives. Ahem.

However, the problem of how to pass long filenames on the command line is a problem of your command shell. Put the filename in quotes. If that doesn't work, your shell is broken. It's not my fault if command.com is obsolete, and I'm not putting hacks into my source port to work around that. Any decent OS has a command line that allows you to pass filenames containing arbitrary characters to other programs.

lobo, you are doing something wrong. i just ran

prboom -iwad c:\doomstuf\doom2\doom2.wad -file "c:\doomstuf\test 1 2 3\r a g e.wad"

from command.com under win98 and it loaded the file fine.

esayeek said:

lobo, you are doing something wrong. i just ran

prboom -iwad c:\doomstuf\doom2\doom2.wad -file "c:\doomstuf\test 1 2 3\r a g e.wad"

from command.com under win98 and it loaded the file fine.

Right let me explain: I could change the EDGE code, for example, and recompile but what about all the people who have EDGE already? The problem isn't that the Feature/Bug annoys me that much (I could always just use directories without spaces like I always have), it's just that I'm coding a front end for EDGE which is basically for MS-DOS virgins to avoid using the command line :-) However, I've also been trying it with other ports as well and I ran the following test with the ports listed above:

I created a response file which contained two commands:

and called this response file like this:

PORTNAME @"c:\launch\response.txt"

and most of the ports crashed. Only one or two actually gave some kind of error message, and from what I saw, most of the ports use a "space" as the delimiter for the commands, which means that they split the command in two at the space (e.g. -file "c:\test wad\misc.wad" is treated like -file "c:\test" and then "wad\misc.wad" which of course is not correct.

As I hope you can see(I suck at explaining in english), the problem isn't long file names (or windows OS), it's the delimiter character that most ports use.

Sorry for the misunderstanding esayeek ;-)

get ZDoom 1.23 Beta X (25 and higher)
you will be able to have folder with space :)

cph said:

I disagree; if you produce a program for Win32 or Linux that doesn't support the normal filenames allowed in th OS then that's a bug. And that includes spaces. Programs that only support 8.3 filenames deserve to be publically humiliated, and programmers who can't cope with that deserve to be punished by being forced to write DOS TSRs for the rest of their natural lives. Ahem.

However, the problem of how to pass long filenames on the command line is a problem of your command shell. Put the filename in quotes. If that doesn't work, your shell is broken. It's not my fault if command.com is obsolete, and I'm not putting hacks into my source port to work around that. Any decent OS has a command line that allows you to pass filenames containing arbitrary characters to other programs.

cph i'm going to refrain from calling you any bad names, and i'm not going to make you code dos TSRs for the rest of your life. now of course you're right in that when you enter something on the commandline, anything in quotes should be in a single argv[] entry and your program should have to do nothing else. but then lobo clarified that it is the response files that he's having a problem with. now the response file was a original feature of doom, and according to you because you ported doom to windows it should have full LFN capability. unfortunately, your response file processer doesn't properly glob arguments in quotes, which makes it non-lfn compatible!! oh mys.

prboom release 2.2.3, d_main.c, line 1004-1012:

        do
{
newargv[indexinfile++] = infile+k;
while(k < size && ((*(infile+k)>= ' '+1) && (*(infile+k)<='z')))
k++;
*(infile+k) = 0;
while(k < size && ((*(infile+k)<= ' ') || (*(infile+k)>'z')))
k++;
}

so please don't be a hyprocrite and fix it.

is that supposed to be ASCII art?

Insomniac said:

is that supposed to be ASCII art?

you don't know C? fine. then don't post in this thread.

Someone's attitude is starting to stink this forum up a bit. It's not much appreciated from a new kid on the block. Relax and take a joke in stride.

You can actually get around the problem of spaces messing things up fairly easily.

1) Type in the first six characters of the folder, ignoring spaces. If there are less than six characters in the folder name, that's fine.

2) Type '~1' (without the quotes) as the last two characters.

The only potential problem I can see if you have two or more folders with the same first six characters (e.g. 'doom wads a-c', 'doom wads d-f', etc), but in this case you just need to figure out what number to use instead of 1.

You'll also find that this is extremely useful if you want to load a LOT of wads at the same time, and you find yourself running out of room in Start->Run.

Biffy said:

Someone's attitude is starting to stink this forum up a bit. It's not much appreciated from a new kid on the block. Relax and take a joke in stride.

then tell me, what does it resemble in ascii art? cuz i can't find any resembelance at all

esayeek said:

then tell me, what does it resemble in ascii art? cuz i can't find any resembelance at all

I don't wish to engage you in a debate, but I'd better answer this so my point is clear. The point is not at all whether that code snippet resembles ASCII art or not, that was a harmless joke by Insomniac.

The point is that I was reading this post with interest and thought that Lobo had initially made a praiseworthy effort in describing his observations and in the thorough listing of the ports affected. From the viewpoint of a user of these things, not a coder of them, I thought Lobo had done some of us a service and his intentions were friendly.

Your harsh words for him took me quite by surprise, especially the part where you called his observations "crap" and accused him of a "holier-than-thou" attitude. Such proclamations appeared to me to be far off base and a more fitting description of your own posts rather than Lobo's. I said nothing at the time.

Looking back at it, I can only guess that his comments hit a nerve somewhere in you, that you replied in the mindset of one of the coders of the ports Lobo mentioned. I could not see the fairness of that mindset at the time because, as I said, Lobo's comments were appreciated by me and I perceived no bad attitude at all in him.

Then, second, you offer that you are going to "refrain from calling cph any bad names" and at the end admonish him not to be a hypocrite.
Attitude starting to smell a bit more.

Then, third, in reply to Insomniac's little joke (we like jokes around here from time to time) you have the nerve to tell a doomworld member not to post in this thread, as if it's your personal property.
Not at all acceptable.

On top of all that, you've not been around here long and I'm not really aware of any contributions you have made to the doom community or individuals on this forum. So, that third strike motivated me to make my comment.

Please treat the forum members, both those who know C and those who don't, with respect. You'll get respect in turn.

esayeek said:
cph i'm going to refrain from calling you any bad names, and i'm not going to make you code dos TSRs for the rest of your life.

Indeed, I acknowlege the problem so you only get to call me names.

but then lobo clarified that it is the response files that he's having a problem with.

I didn't read that in his first post, now he's clarified it I see where the problem is.

now the response file was a original feature of doom, and according to you because you ported doom to windows it should have full LFN capability.

s/windows/linux/ and I agree. It is gong on the bug list now, and should be fixed for the next release.

Thanks for the bug report Lobo. BTW I don't always read the forums, so posting to our sourceforge site or the prboom mailing lists is a more reliable way of reporting buts.

Oh, and please please please don't use shortnames (~1 madness) to work around this in a front-end except as an optional fallback when it's unavoidable. There's no way to be sure you get the right shortname for a file AFAIK, and there's no guarantee they're even enabled (they can be turned off, and MS guidelines recommend doing so in some situations).

cph said:

Oh, and please please please don't use shortnames (~1 madness) to work around this in a front-end except as an optional fallback when it's unavoidable. There's no way to be sure you get the right shortname for a file AFAIK, and there's no guarantee they're even enabled (they can be turned off, and MS guidelines recommend doing so in some situations).

It did cross my mind when I first encountered the problem, but I foresaw that it would be much more trouble than it's worth.

I will just have to hope that the people who use my front end don't have their ports/pwads/iwads in directories with spaces :-( and advise them of the possible problems if they do. Thanks for the advice CPH.

BTW, I just love when people send me bug reports, so I figured everyone else would like them too ;-)

cph said:

Oh, and please please please don't use shortnames (~1 madness) to work around this in a front-end except as an optional fallback when it's unavoidable. There's no way to be sure you get the right shortname for a file AFAIK, and there's no guarantee they're even enabled (they can be turned off, and MS guidelines recommend doing so in some situations).

if there are multiple filenames with the same 6 letters, there will be ~2, ~3, etc; the shortname can be just about anything and doesnt nessecarily have to have ~# in it (some obscure windows settings somewhere allow other short names); to add to cph's post.

In Vavoom quotes should work just fine. But if you are using a response file, then it won't work.

BTW To have LFNs in DJGPP programs, you must run them under Windows, pure DOS doesn't support LFNs.

Retox said:

In Vavoom quotes should work just fine. But if you are using a response file, then it won't work.

BTW To have LFNs in DJGPP programs, you must run them under Windows, pure DOS doesn't support LFNs.

to get technical, you must run them under windows or a dos enviornment with a tsr that supports the int 12 (at least i think it's 12) extensions =D

cph said:

Oh, and please please please don't use shortnames (~1 madness) to work around this in a front-end except as an optional fallback when it's unavoidable. There's no way to be sure you get the right shortname for a file AFAIK, and there's no guarantee they're even enabled (they can be turned off, and MS guidelines recommend doing so in some situations).

unsigned long GetShortPathName(LPCSTR lfn, LPCSTR buffer, int len)

Retrieves the correct short file name for any long file name. Also, I'm almost 100% certain that SFNs cannot be disabled -- LFNs CAN be disabled, however, I know that for certain. Maybe that's what you were thinking about?

Microsoft's recommendation wrt SFNs is to avoid them when possible, and to not store them in a config file or the registry, as when a file is moved, its SFN can change in response to the presence of other files with the same SFN. However, most people don't move their DOOM files around that much, so a frontend would be reasonable in expecting path names to remain stable. And of course, there's always the ability to TELL the user in the documentation that they need to reselect the files after moving them. Its not that bad really.

BTW, Eternity doesn't support LFNs yet from the command line, but it does fine with any LFNs that are used implicitly by the program, such as in the IWAD path, etc. LFNs really mess up the tokenization of the command line and are a pain, IMNSHO. I don't consider it a priority problem. And you can't make me program any TSR's, cph, I'll run away and hide ;)

Quasar said:
unsigned long GetShortPathName(LPCSTR lfn, LPCSTR buffer, int len)

I stand corrected. That's a fair workaround then.

I'm almost 100% certain that SFNs cannot be disabled

LFNs really mess up the tokenization of the command line and are a pain, IMNSHO.

Computers are for the convenience of end-users, not programmers. Just grab the new FindResponseFile from the PrBoom CVS or I'll have to come up with some TSR ideas ;-)