I was working on a Ruby program and had issues that I finally found out were caused by the default encoding in Windows 10 terminal, which apparently is CP850, an encoding so old it doesn't even include the € symbol. I read that, of course, if I try to change this other programs around the computer will give issues.
Wikipedia indicates that CP850 has theorically been "largely replaced" by Windows-1252 and, later, Unicode, and yet it's here, right in the OS's terminal.
Picture attached as proof. It's in italian language but you'll see it under "Tabella codici corrente", aka "Current code table".
How's that possible?
This is historical.
DOS had cp437, and later cp850 (and e.g. also cp852) as standard code page.
Terminal in Windows was also known as "DOS prompt": so a way to run DOS programs in Windows, so they keep the code page of DOS. Microsoft dislikes non-backward compatible changes, so your DOS program should works also on Windows terminal without problem.
Windows-1252, as the name stress it out, was done for Windows, so no compatibility problem, and for Windows programs, but so, in order to gain graphical interface market, but keeping compatibility with many business applications, Microsoft maintained two different code page.
Related
I've been using GSView 5.0 and GhostScript 9.52 to do postscript printing on vellums. However, today GSView started throwing error codes on every .ps file I've attempted to print. I'm using Windows 10 Pro and the printer is an Epson Artisan 1430.
The error is as follows:
GPL Ghostscript 9.52: **** Could not open file 00000e60.
Unrecoverable error: invalidfileaccess in showpage
Operand stack:
--nostringval-- 1 true
gsapi_execute_cont returns -9
gsapi_exit returns 0
I've tried changing permissions for the files and different printer drivers to no avail. I'm sorry I can't be more descriptive on this issue as it's hard to articulate.
OK... You must have recently updated to a new version of Ghostscript. I can reproduce your problem, and it comes down to a recent (documented) change in behaviour for Ghostscript.
Due to the well-documented public disclosure of security exploits using Ghostscript a couple of years ago, the current version (and any version since 9.50) now defaults to running in SAFER mode.
When running in SAFER, Ghostscript prevents access by the PostScript interpreter to the file system. For those unaware of the problem; PostScript is a full-blown programming language and, by design, permits programs to access the underlying file system. SAFER mode prevents this so that malicious PostScript programs cannot, for example, run arbitrary code on your computer.
It seems that GSView is using Ghostscript in a way which requires it to read the PostScript program to be printed using the PostScript interpreter, instead of the more normal practice of specifying the input file as one of the arguments. For simplicity the input file is granted read availability by the Ghostscript executable. I suspect that GSview is using the DLL directly and not adding that extra information.
Now there are ways to permit access to specific files or folders, so that existing PostScript programs can continue to work, but obviously this requires some changes in the calling application. GSview has not changed in, literally, years so obviously it does not take any such action.
You can, however, get GSview to work as before. Under Options select Advanced Configure. In the resulting dialog look for the 'Ghostscript options' text box. In there add -dNOSAFER, that should get it to work again, though you may have to reboot the computer if the OS print subsystem has stalled.
Yes, this does open you up to the sorts of exploits I alluded to above, you should only do this with PostScript programs that you trust.
I would like to find out which version of Electron an Electron desktop app like Signal Desktop or Visual Studio Code is using. Is there a simple way - like entering a command in the Development Console?
Thanks! Johannes
(Why? I would like to see if it is affected by bugs like https://www.trustwave.com/Resources/SpiderLabs-Blog/CVE-2018-1000136---Electron-nodeIntegration-Bypass/)
You can, if the App enabled developer tools and enabled nodeIntegration. take VS Code as an example:
open the Developer Tools, in the console tab, type
process.versions.electron
documentation here: https://electronjs.org/docs/api/process
or try parsing version from userAgent string
navigator.userAgent.match(/Electron\/([\d\.]+\d+)/)[1]
Open the Developer tools and in the Console tab type:
navigator.userAgent
For example in the Discord app I'm getting:
Mozilla/5.0 ... Electron/9.3.5 ...
Under a Unix-like or Linux system (and possibly under Windows using Cygwin or MSYS shells or WSL, but this is untested there), you can use the strings program even for progams that are built without the developer tools enabled.
Basically, you're just searching for a user-agent string in the binary itself.
Currently, I have been able to do the following:
$ strings example-electron-app-binary-file | grep '^Chrome/[0-9.]* Electron/[0-9]'
Chrome/98.0.4758.141 Electron/17.4.7
That regular expression searches for strings starting with Chrome/, followed by any number of numerical digit and dot characters, a single space, and then Electron/ with any numerical digit after it.
This won't work in all likelihood if your system uses UTF-16 strings, but since browsers tend to use UTF-8 internally there's still a chance it'd work on a Windows electron binary.
Is it Possible to create bootable (Applications for MBR )application using Delphi or Pascal (I know we cant use vcl , RTL and other stuffs because they depend on OS), but can i use at least Readln and writeln.
If it is true !!! Can we run the program under other OS.
but i know that PE (windows) and ELF (Linux ) formats are different. but at least with some small modification can i do it.
It's worth saying that PE is a very diverse format than ELF.
Not only a few bytes to modify... the whole layout and library access is diverse, and binding is totally diverse.
In order to boot Delphi application in console mode, you can put a small DOS system (take a look at FreeDOS, for instance), then run your Delphi application using for instance DWPL. DWPL allows to run native 32-bit protected mode DOS programs with Delphi 5-7 using the WDOSX DOS extender as the core. I used this in some old hardware with a network adapter, and it worked like a charm. If you are interested in it, I could post some updated code of DWPL.
For such targets, you should take a look at Free Pascal. By nature, you can customize it to whatever target you want. There is even diverse draft Operating Systems written using FPC. See for instance Toro or ClassiOS - the latest uses Delphi executables as source.
You can see the boot code of Toro from here, and a "main program" source code created with it.
But for direct booting applications, booting is not so difficult. The real problem is the hardware layer.
The BIOS gives very little access to it.
Just for the network layer, you'll have to take a look at EtherBoot sites and such to get some low-level network access... but it could be very time consuming to rewrite all those drivers by hand!
In short: all those "pure pascal" OS are only theoretical, running a console and some low-performance network (emulating a poor network adapter like NE2000 or such). So those "pascal" OS are only proof of concept. FAR away from a working solution! But very nice technological challenge, in all cases, very inspiring.
Why reinvent the wheel? If you want a light and fast system, use a custom Linux kernel.
Then use CrossKylix to compile your Delphi application (with no User Interface) into Linux, or even better Free Pascal.
You don't really place "applications" in the MBR.
The entire size of an MBR is 512 bytes, of which you can only use 446 for code.
Good luck creating something useful in that if you don't even have an OS to delegate functionality to yet. Basically all that you can do in the MBR is place code to start a boot loader.
Here's a page with disassembly of an MBR:
http://www.dewassoc.com/kbase/hard_drives/master_boot_record.htm
Why must you write the boot loader?
You could use a ready-made bootloader like GRUB and chainload your PE executable, from it.
Of course, this is very ancient and hairy stuff, but in the good old days, people did this win PE format executables, and a DOS Extender.
For something a little more this-century, why not make your own bootable REACTOS disk, and add your own PE executable written in Delphi to handle the "user shell"?
You could also (but this would require licensing) use the Windows PXE. I think that projects like BartPE probably fall on the gray side of legal, or are at least, unlicensed. Thus, a completely MS-free solution (reactos) for a completely self-contained kiosk PC, with ReactOS, might be more what you are looking for.
Can you write your own operating system? your own UI layer? your own video device drivers? I didn't think so. So use DOS and TurboPascal, or ReactOS and a PE win executable. Or you can use FreePascal and just build your app on a very lightweight portable Linux kernel and root filesystem.
I have been asked to update a program written in 1987 in Delphi (I guess). I have no documentation about this program only a few side notes the programmer took that don't make too much sense to make.
The cd show this files:
Size | Filename
19956 VP.DTA
142300 VP.LEX
404 VP.NDX
126502 VP.RCS
131016 VP.SCR
150067 VP.XEL
101791 vp.exe
Is anyone of this files a database? If so can I access it's data?
I tried several code decompilers but they show a message saying it was not a Win32 compatible application.
The program run in MS-DOS.
Is it possible to obtain the source code? Can I use this code in any way to build a new application?
Update01: I can run the program in MS-DOS. The program conjugate verbs and shows an example sentence where the verb can be used. The GUI is a little bit confusing and there is no help menu so I can't see all the capabilities of the program.
Update02: In conversation with the owner of the program we found another solution. He ask me if it was possible to have the program in a server and the clients could login in with a user and a password and execute the program in a terminal. I have an account in my university server, which I can access throughout ssh and compile and execute c programs in it. The server is in linux so I couldn't try the program in it. If I set up a windows server, can I have multiple people accessing and executing the program in a terminal? The program is an exe. Doesn't this raise some security issues?
Delphi is from mid nineties, so that probably means Delphi's ancestor Turbo Pascal, not Delphi.
Some extensions sound familiar, as shortened versions of words:
ndx = index
dta = data
scr = screen (?)
lex = lexicon (list of words or deduped strings in general) (?)
Screen was sometimes used for e.g. helpscreens, a medieval form of helpfiles, they are typicall ansi screens that can be loaded directly into screen memory
There is a fair chance that this is something handcrafted, specially if that date of 1987 and the general assumption "pascal" is true, and not generated by some known database package at all.
Reverseengineering the fileformat might be a more worthwhile way than trying to reverseengineering the app.
A good start would to be to take a the unix "file" command to see if it can recognize the file types. (the file command searches for signatures inside files, and there are windows ports. I use Cygwin's)
A devel experienced in such matters can also see a lot from a hexdump (specially the first parts of a file)
Is it possible to obtain the source code?
Probably not, you may want to look at something like IDA Pro which can disassemble applications to C using something like Hex-Rays.
Do you know what the application is supposed to be?
If it's ms-dos, you're probably better off just drawing up new requirements and doing new development.
Look for DeDe to reverse engineering a delphi compiled program. But as far as i know, delphi is a real compiler. So there is no way to de-compiled it. If you are able to read assembler code then you can try de-compile it. Clipper and Foxpro (dos version) are another stories cause they not real compiler.
This is definitely not Delphi. It might be one of the database centric languages like Clipper 1. .SCR probably means "screen" and defines I/O masks. .NDX is a table index and .DTA means "data".
If it is clipper, you might actually be lucky, because as far as I remember these programs were P code, so it could be possible to decompile it.
It looks like CLipper (NDX and SCR). If you have a DBF file then it's Clipper for sure. But some people renamed the DBF to something like DAT. If it is Clipper, I believe there was a decompile named Valkyrie.
What Windows code editors allow the use of elastic tabstops, either natively or through a plugin?
I know about a gedit plugin, but it only works on Linux.
Code Browser may be the first for windows. I would love to see this feature as a plugin for other editors as well.
I did quite a bit of googling trying to find this answer. There are plenty of people asking for it:
http://developers.slashdot.org/comments.pl?sid=414610&cid=21996944
http://www.arguingwithmyself.com/archives/75-the-biggest-feature-your-editor-is-missing
http://intype.info/blog/screencast-parser-in-editor/#comment-221
http://codewords.wordpress.com/2006/10/16/eclipses-achilles-heel/
just to name a few...
so I don't think one exists yet, sorry :(
Code Browser supports elastic tabstops, but it appears to be the only thing for Windows that currently supports it. Unfortunately, it has an unusual UI which may render it unsuitable for multi-person projects, and may even make it difficult for you to use even if no other editors are involved.
According to the elastic tabtops website, he's working on plugins for eclipse and Visual Studio 2010 (though the Eclipse plugin is stalled pending a bugfix, and jedit should support elastic tabstops in an upcoming version.
Finally, though this probably isn't an option, you could try running an x server (such as Cygwin/X or Xming on your Windows computer and ssh into a Linux client (either a virtual machine or another computer) to run Gedit. This approach has many problems though: you need to keep your files on a separate computer (perhaps using Dropbox to keep them in sync), X over SSH is notoriously slow, and you need either another computer or a virtual machine.
XMLQuire is an XML editor developed for windows to showcase virtual formatting. This concept goes a step further than elastic tabstops, indentation is simply a function of the position of the preceding line-feed character and the nesting level and context assessed by the parser:
It's the XML parser that determines the nesting level and therefore the required indentation, there's no reformat key or tab key to press, the XML formatting just reflows as you edit, drag and drop etc.
This means that XML is always properly indented, but without leading tabs or spaces. The concept should also work for more conventional code (except for languages like F# that exploit whitespace), but this has not yet been tried out.
Note that, unlike elastic tabstops, virtual formatting only works from the left-margin and only uses the parser context. The parser context is more than just about nesting level though, factors such as mixed content, node-type, length of parent element name and attribute name all come into the equation. This allows alignment of attributes and attribute values that occur on new lines also (as shown).
Word-wrapped text naturally just fits to the indentation scheme. If further text formatting is required then space characters are added by the user in the conventional way.
As with elastic tabstops there's a potential issue when virtually formatted text is opened in a more conventional editor. However, because no characters have been added for XML formatting (it was all virtual), conventional editors can simply apply conventional formatting according to the settings for that editor, uses tabs or spaces.
Here's a elastic tabstop plugin for Visual Studio 2010 by ferveo (Ramunas Geciauskas):
http://visualstudiogallery.msdn.microsoft.com/ccff2b55-201f-4263-aea5-3e66024d6c0e
Another option is jedit which has already added support for elastic tabstops. It is available on Windows, Linux, OS X, and Unix.
The problem is that only a few toolkits/platforms have text widgets that offer the ability to set non-uniform tabstops on different lines. To my knowledge, those toolkits/platforms are Java Swing (used by the demo on the elastic tabstops page), GTK (used by Gedit and the Gedit plugin), and apparently the new version of Visual Studio (VS 2010).
Expect to (eventually) see more developments on all of those platforms.
Textadept has an elastic tabstop plugin.
Atom also has a plugin.