Utilitário útil da semana: doskey

Read this post in English

Se você usa o console (cmd.exe) do Windows em suas tarefas diárias, você deve ser uma pessoa bem infeliz :)

Brincadeira a parte, deixe me explicar: você deveria usar um console melhor, e como eu frise, no windows temos algumas opções).

Mas o objetivo deste post é na realidade, falar sobre um utilitário que acompanha o Windows e que pode tornar sua experiência com consoles melhor; trata-se do doskey um aplicativo capaz, dentre outras coisas, de criar aliases, ou seja, "apelidos" para comandos (eu verifiquei no Windows 7 / 8 mas me lembro de utilizar um aplicativo com o mesmo nome no DOS 4.2).

No meu caso constantemente necessito abrir um arquivo texto em um editor (eu gosto muito to Sublime e também do Notepad++); para simplificar tal tarefa eu normalmente abro o console e a primeira coisa que eu digito é:

doskey subl = "%ProgramFiles%\Sublime Text 2\sublime_text.exe" $* 

a partir deste momento posso digitar o seguinte comando no console para abrir um arquivo de textos no Sublime:

subl meu-arquyivo-texto.ext

Bom fim de semana!

Happy coding.

Utilitário útil da semana: Clip

Se você é um usuário do Windows um pouco mais avançado e utiliza o console (cmd.exe) é provável que recorra ao menu de contexto quando necessita copiar qualquer conteúdo do console para a área de transferência (clipboard) do Windows.  

Você sabia que o Windows (pelo menos a partir do Windows  7) vem com um utilitário chamado clip que permite que você copie qualquer conteúdo passado para sua entrada padrão (stdin) para a área de transferência? Por exemplo você pode copiar o resultado de um dir para o clipboard com a seguinte linha de comando:

c:\temp>dir | clip

É claro que você também pode redirecionar a entrada padrão:

c:\temp>clip < arquivo.txt

Não sei quanto a você, mas quando eu descobri este pequeno utilitário minha vida no console ficou muito mais fácil.

(Este post em Inglês)

Utilitário útil da semana: ConEmu

Se você é um usuário avançado do Windows provavelmente recorre ao console (cmd.exe) para executar várias das suas tarefas diárias. Eu, em geral, tenho 2 ~ 3 consoles abertos normalmente e este fato é exatamente a motivação deste post.

Vamos ser sinceros: se você já usou algum shell (tipo bash) que acompanha uma instalação Linux moderna usar o console do Windows dá vontade de mudar para o Linux ;)

Felizmente não é necessário uma mudança tão radical (muito embora eu recomendo usar o Linux, ou qualquer outro S.O. sempre que possível). Por exemplo, a algum tempo eu vinha usando o console2 que é uma boa alternativa ao console do Windows. Recentemente eu passei a usar o ConEmu simplesmente porque o mesmo tem sido atualizado mais frequentemente que o console2 (de qualquer forma eu recomendo instalar ambos e experimentar para ver qual lhe agrada mais).

Entre outros recursos o ConEmu suporta múltiplas tabs, seleção de texto muito melhorado, uso de qualquer fonte, etc.

Quanto a mim, não pretendo voltar a usar o console do Windows (talvez, quem sabe, usar mais o power shell, mas isto já é assunto para outro post :).

(This post in English)

Free (open source) RAM disk for Windows (x86 / x64)

Hi


Have you ever had the need to perform some I/O intensive operation on a relative small set of files? I do, usually when I need to compile some application.

In order to speed up this operation I've recurred to the so called "RAM Disks", applications that takes part of your computer's main memory and pretends that it is an actual disk. As you can imagine read/write/etc (I/O) operations against this virtual disk are much faster than operations against your actual hard disks (be it a traditional magnetic HD or a shine new SSD).

In the past 3 years I've used at least 3 different solutions and was happy with none. My main complain is that most of them were not capable (or it was really clumsy/hard to accomplish) of creating RAM disks dynamically, i.e, one is required to create it at OS start up time. Since my needs are dynamic (I may need more disk space at some points in time during the day) it is really hard to come up with a disk size that work for me: choose a to big disk and I am wasting precious RAM space; create a disk that's to small and I may find myself facing "out of disk space" errors (then cleaning up some junk and restarting my build tasks).

Fortunately some time ago I stumbled upon a RAM disk implementation that allows me to mount and unmount disks dynamically! Since then my work flow has been much more smooth ;) The not so good side is that it is not very easy for the "not computer savvy" user.

Bottom line is: if you need a stable and flexible (but maybe not so easy to start with) RAM disk solution you can't go wrong with this one.

Redirecting standard error output in cmd.exe

Hi. Suppose you have the following C++ program (in a Windows box):

#include "stdafx.h"
#include "string.h"


void write(char *str, FILE *target)
{
fwrite(str, strlen(str), 1, target);
}

void _tmain(int argc, _TCHAR* argv[])
{
write("Test:stderr\r\n", stderr);
write("Test:stdout\r\n", stdout);
}

and you want to redirect its output to a file. We could try something like in Windows console:

test.exe > myfile.txt

Unfortunately the naive approach don't work because there are data being outputted to stderr and we are redirecting only the standard output (stdout). In order to redirect stderr we can use the following syntax:

command handler# > target

let's try a sample:

test.exe 1>myfile.txt

This will redirect stdout (handle 1) to myfile.txt To redirect stderr (handle 2) we can use:

test.exe 2>myfile.txt

Ok. Now we can try:

test.exe > myfile.txt 2>myfile.txt

but, again, this doesn't work; instead we get an error message:

D:\temp\cpp\Test\Debug>Test > myfile.txt 2>myfile.txt
The process cannot access the file because it is being used by another process.

Ok, there's one last trick we can try (duplicate stderr to stdout):

test.exe > myfile.txt 2>&1

Great! Now it works as expected! Last, but not least, you can find more information here. Hope this can be useful :) Adriano

"COM" não esta morto (pelo menos eu espero)

Assim como a morte de linguagens de programação como Cobol, Fortram, Basic, etc. e também a extinção dos programadores já foram anunciadas várias vezes, mas nunca se concretizaram ,graças a Deus, muitos já anunciaram a morte do COM (Component Object Model), uma tecnologia da MS para a componentização de soluções. Infelizmente (para estes "gurus" !) isso não aconteceu (preciso dizer: "eu já sabia que isso não aconteceria mesmo") ? Pelo contrário, se você observar o número de sub-sistemas do Windows Vista implementado usando esta tecnologia você irá notar um aumento razoável no número de componentes neste SO. Como grande parte da minha carreira foi dedicada a esta tecnologia é natural que eu tenha interesse nesta :). Assim, a alguns anos atrás (para ser mais preciso, entre 2002 e 2004), eu escrevi (e disponibilizei gratuitamente) um utilitário (ao qual chamei de Typelib Wizard) que, entre outras coisas, permite fazer Browse do conteúdo de TLBs (quer estas TLBs estejam isoladas ou incluídas como recurso de um executável) mais ou menos nos moldes dos browsers de classes encontrados nos ambientes de desenvolvimento atuais. Se você desenvolve componentes COM (ou se utiliza ambientes tais como ASP (não ASP.NET), VB 6, VBA, Power Builder, etc., em que a chance de estar utilizando componentes COM, mesmo sem saber, é grande) esta ferramenta é de grande utilidade. A algum tempo eu não realizo nenhuma manutenção no projeto mas tenho algumas idéias e seria um prazer adicionar outros desenvolvedores para que os mesmos possam atualizar o repositório de código (que aliás, vou passar para o subversion) e ajudar a manter o projeto "andando". Para saber mais sobre o projeto visite os sites abaixo:

• http://typelibwizard.sourceforge.net/
• http://sf.net/projects/typelibwizard

Abraços. Adriano

SerialWizard: Uau! 1649 Downloads (1 Gb!)

Quando comparado com outros aplicativos pode não parecer muito, mas para mim realmente é um número expressivo: o SerialWizard já foi baixado 1649 vezes totalizando 1 Gb ! Se tiver curiosidade para saber como o SerialWizard esta neste momento click aqui.

Aplicativo (útil) da Semana - Parte 2

Como sempre a falta de tempo tem me impedido de postar mais frequentemente :( De qualquer forma, hoje pretendo apresentar um aplicativo bastante útil que usuários do Unix/Linux já estam bastante acostumados mas, por motivos que não importam, a marioria dos usuários do Windows desconhecem. Quando comecei a trabalhar na empresa que me encontro atualmente me deparei com a seguinte situação: todos os desenvolvedores criavam uma estrutura de diretórios fixa (por exemplo: c:\Projetos\NomeProjeto, ou algo parecido) e algumas ferramentas dependiam destes caminhos (pois usavam caminhos absolutos). Como sempre tive o habito de particionar meus HDs em pelo menos duas partições (uma para dados e a outra para programas) o drive C ficou para o SO (sistema operacional) e a partição de dados acabou ficando como E (ok, eu sei que posso mudar este mapeamento, mas eu não queria fazer isto por outros motivos). Para resolver este impasse (eu desejava colocar o diretório de projetos no drive E, mas algumas ferramentas esperavam que o mesmo se encontrasse no drive C) eu criei um Junction Point (ou ponto de junção) no drive C apontando para o drive E. Junction Points permitem que sejam criados links para diretórios em qualquer volume (por exemplo o diretório c:\projetos pode ser um Junction Point, ou seja, pode apontar, para o diretório c:\meus documentos\projetos). Assim, para solucionar o impasse fiz o seguinte:

• Criei a estrutura de diretórios no drive E (E:\Projetos\Nome Projeto)
• No drive C eu criei um Junction Point chamado Projetos apontando para E:\Projetos
• desta forma ao acessar o diretório c:\Projetos na realidade estou acessando E:\Projetos.

O resultado pode ser visto na seguinte imagem: Observe que o c:\Projetos aparece no console como JUNCTION (e não como DIR como os demais diretórios) enquando e:\Projetos é apresentado (como era de se esperar) como DIR, indicando que o mesmo é um diretório comum. Agora, todas as operações que forem realizadas em c:\projetos na realidade estarão sendo realizadas em e:\projetos. E como criamos (manipulamos) Junction Points? A resposta rápida é que apesar do Windows suportar Junction Points desde o Windows 2000, por algum motivo que desconheço, a MS não possui uma forma simples para manipular Junction Points (aqui você pode encontrar explicações [em inglês] de como criar Junction Points com ferramentas da própria MS). Porém nem tudo esta perdido :). Você pode encontrar utilitários (gratuítos) que manipulam Junction Points aqui, aqui e aqui. Eu, particularmente, uso a primeira delas pois a mesma permite criar também Hard Links e Symbolik Links (no Windows Vista) além de possuir versões para x86 e x64.